AWS Summit Tokyo 2019 最終日の午後のみ参加
毎年恒例になっているAWS Summit Tokyo、今年は何と幕張。遠い。。Tokyoじゃないじゃん。しかもInteropと同日開催。と言いたいことだけ言ってるけど、今年は3日目の午後しか参加できませんでした。会社の同僚は気合いいれて幕張に宿とって二日とか参加してたけど、仕事云々ありまして、、はい。
でもって初日二日目（とre:Mix）には参加できず、Day3の13時の講演から参加。三日間ともKeynoteは今ひとつだったという声もチラホラあったのでまあいいか？！
最初はちょっと遅れてクラスメソッド横田さんの「キャッシュレスでウォークスルー「Developers.IO CAFE」～小売の最新型をAWSで構築～」。過去に何度かこの話を聞けそうなイベントはあったけど行けなかった（聴けなかった）のもあり。
内容的には横田さんがAmazon Goを実体験し感動したことをDevelopers.IO CAFEとして実現する（そして現在進行形）までの経緯、進め方、そして顧客のために事業をするということについて。このセッションは、Amazon Goの仕組みがどうだとか（基本ブラックボックスだったけど先日のre:Markで構成図が出たらしい）、Developers.IO CAFEの仕組みがどうだとか、ということより、IT会社が事業会社になってもいいじゃないか、という考えの元、横田さんが顧客体験を徹底的に追求して、スピード感のある開発をして、またその顧客体験からフィードバックして、ということを繰り返している事業の基本のことなのかな、と。
要件定義書は自分の体験に基づく実現したいことの動画、開発途中の報告アウトプットも動画。体験を設計し伝えるというデザインシンキングにも近い進め方で、各フェーズはメンバーアサインから完了まで３ヶ月でやりきるというスピード。ここらへんが一番ためになったかも。お客様は慣れると元に戻れない＝リピーター、というのもリカーリングモデルに繋がる考え方で参考になる。
で次はお目当てToriさん(toricls)による「サービスメッシュは本当に必要なのか、何を解決するのか」。今回から取り入れらたサイレントセッション（聴講者は全員レシーバーを使ってイヤホンで講演を聞くスタイル）は斬新だったが、登壇してる方は客の反応見にくくてどうなんだろうねー。
でToriさんはいつも通りAWSの中の人っぽくない格好で（？）、モノリス→マイクロサービス、その課題とサービスメッシュの説明、そして本当に必要なのは何か、必要なら、という締めくくり。いつも通り説明がわかりやすく、まずはモノリスなアプリの課題を再整理。
- 関係者間の調整のオーバーヘッド（デプロイタイミングに影響）
- 非効率なスケーリング（関係ない部分も一緒にスケールしちゃう）
などなど。これをマイクロサービスにすることで期待される効果として、
- 変更による影響範囲の局所化
- モジュール境界の維持し易さ（モジュールを綺麗に作っていれば）
- 独立したデプロイとスケーリング
- 自立的なチームによる開発と運用
メリットでもありデメリットとして
- Polyglot(-table) ← ってどういう意味？？多言語？いろんな言語でアプリ作れる（チームごとに）ってこと？
モノリスでもマイクロサービスでも、X-RayのようなAPMを利用すれば不具合発生時の調査はできる。ただマイクロサービスはその特性として、サービスが増えれば増えるほど複雑な通信図となってしまう。そんなマイクロサービスの課題としては、
- サービスの適切な分割（正解がない。状況や環境次第）
- テストも難しい
- 影響範囲を自分のサービスにおさめるのも難しい（合意無しにAPIの後方互換性を崩せない、ダウンタイムも出せない）
さらに
- サービス間通信の信頼性
- サービス間通信の可観測性
ここがら本題ということでした。（そろそろ溢れ出るメッシュ感を感じられるか？？）
マイクロサービスは防御的実装が必要であり、サービス間通信の信頼性を高める実装としては、
- 呼び出し先サービス位置は一定でない（コンテナどこで動いてるかわからない）→ サービスディスカバリ
- 一時的な呼び出し失敗 →リトライ
- 継続した呼び出しの失敗（何度も失敗してたら呼び出しをやめるべきだし、お客様に迷惑をかける、対向側の復旧にも迷惑） → サーキットブレーカー
- 呼び出し先サービスのパフォーマンス悪化 →タイムアウト
- 呼び出し元システムの不具合 → スロットリング
ふむふむ、とてもわかりやすい説明だ。サーキットブレーカーの意味がやっとわかった :-)
続いて可観測性については
- 失敗がどこでなぜおきたのか、わかる必要がある。それはモノリスも同じ。(前半にも同じ話あり）
- どんどん増えるマイクロサービスに、個別実装頼み切れるのか。統一フォーマットにしたら変更のときどうするのか、大変。
- →共通ライブラリが密結合を生んでしまう。
解決策として、
- プロキシへのオフロード＝サービスメッシュ
必ずプロキシを経由してアプリ同士が通信する。そこでリトライとかタイムアウトとか制御する。Envoyがこれ。 - App Mesh・・・Envoyに動的に設定を反映。AWSはここにもすでにマネージドを用意している。→ これは便利そうだなー。
コンテナ界隈の勉強をしていた頃に追いつけていなかったサービスメッシュの概念や仕組みへの理解がとても進んだ気がする。さすがToriさんの説明すな。
で最後に、「あなたのサービスにサービスメッシュは必要ですか？課題に対する必要性を考えるべきでは？」「x-rayやALBで十分な場合も。App Mesh使わなくてもいいんでは？」とAWSのSpecialist Solutions Architect, Containersらしからぬ発言？をしたところで、セッションは終了。急に終わった。続きを聞きたくなる終わり方だぜ。。
その後は会場でも話題になっていた？パイプ椅子でお尻が痛い問題もあり（？）、少し各社のブースを覗きつつ休憩タイムに。途中までなのにアンケートに答えてアイスをもらい、その後 Certifiedラウンジへ。今や有資格者多過ぎてあまり優越感に浸れない感じの混雑ぶり、、飲み物も一つも残っていなかったが、何とかペロペロキャンディーをゲット。子供へのみやげができました。
その後もフラフラしてたら、やっと弊社のブースを発見。懐かしいメンバーに声をかけられしばらく立ち話。行こうと思っていたミクシィのセッションは会場が遠すぎるので諦め、ブース真ん中のミニセッションにてマクニカ野原さんのTwistlockの話を聞く。コンテナのセキュリティは重要になってくると思うけど、セキュリティ製品って難しい。どうしてもお金がかかるのでなかなか軽くいれられないし、サービスにするにも費用面でのモデルが立てづらいんだよなー、、。しかもTwistlockはパロアルトに買収されてしまったという難しい状況。。
最後のセッションはAWS福井さんの「クラウドネイティブなモダンアプリケーション開発を始めよう！クラウドネイティブ設計とデプロイメントパターン」。AWSモダンアプリケーションプラットフォーム、群というんですね。各マネージドサービスを利用したアプリのモダン化のパターンの説明だったが、おさらい的な感じで初級者向けだったかな。
帰りに会社の同僚と話をしたが、昨年も感じたようにエンタープライズ寄りの内容に進み、Keynoteも事例紹介中心？な感じのようだ。re:InventのようなDeveloper向けの要素が薄れているので、ちょっと参加する層も変わってくるかもですね、、2年前はDev Dayもあった気がするので、そっちも充実させた方がよいのかも？！