ワーナーさんのキーノートを現地で見ました (山下) その3 | AWS re:Invent 2024参加レポート
2024年12月最初の週にAWS最大のグローバルイベントにして世界最大のクラウドカンファレンス AWS re:Invent 2024 が開催されました。
このブログはAWSのワーナー・ヴォゲルスさんのキーノートをラスベガス現地で目の前で見て感じたことを全3回に渡りレポートしています。
キーノートの内容そのものを知りたい方はYoutubeで動画が公開されていますのでそちらをご覧ください。
また、そもそもAWSって何？詳しく知りたいという方は、こちらの「AWSとは？AWS認定講師が解説」をご覧ください。
セルベースアーキテクチャ
ハッシュキーなどにより特定のユーザーや特定のデータリクエストのみを処理する、"セル"という単位にサービスを分けるセルベースアーキテクチャ。
セルは地域的に分散することもあったり、特定のユーザーごとに分散したりして設計することもあります。
こうして問題の影響がほかのセルに及ぶことがないようにし、全体的な信頼性を高めたり、管理しやすくします。
サービスがスケールしてユーザーが増えた場合も、例えば新たなセルを構築して割り当てれば既存のセルには影響を与えないことになります。
昔、LAMP環境のセットを事業別に分けていましたが、ものすごくシンプルなセルベースアーキテクチャだったのかもしれません。
Simpler approachと書かれたリソースの設定変更を処理するアーキテクチャの例です。
設定変更が指示されると、それをファイルに書き込んでS3バケットに保存します。
リソース側からS3バケットの新しいファイルを取得して処理します。
こうすることで、同時実行数に制限がある設定変更処理を同レベルに維持しています。
この設計パターンは、Constant Workパターンと呼ばれています。
とにかくS3を挟むのは、後々のデータ分析にも非常に有効なんですよね。
Route 53のヘルスチェックでもこのConstant Work設計がされているそうです。
アーキテクチャのアイコンはS3バケットではないので、保存先は違うものが使用されているようです。
何を自動化するのか？で考えるのではなく、何を自動化しないのか？で考えます。
人がやることを例外として考えて、人の判断が絶対に必要なところだけは人がやります。
それ以外は全部自動化します。
多くの自動化を行っている分野がセキュリティ。
セキュリティを守るためには、みんながセキュリティを大事にしないといけません。
だから責任共有モデルが言いたいことは、責任分解点じゃないんですよね。
責任のなすりつけあいを言ってるんではなく、自分が大事にするべき範囲を認識して実施するということですね。
相手側に足りないものやニーズがあるなら、私たちはAWSにフィードバックしますし、AWSは私たちにユースケースやベストプラクティスを共有します。
AWSではセキュリティサポートチケットの処理に、Agentic Workflowなる設計を使用しているそうです。
この設計はServerless Agentic Workflows with Amazon Bedrockというオンデマンドトレーニングで公開されているので、やってみなければですね。
Too Good To Goの場合
フードロスの削減に取り組むToo Good To Goさんが登場しました。
なんと！世界中で生産されている食品の40%が廃棄されているそうです。
2015年にこの問題にを解決するべく起業家たちによって設立されました。
余剰食品を割引価格で販売する仕組みで、2018年には100万ユーザーにまでなりました。
創業者たちは理念も素晴らしくビジネスのセンスもあったが、エンジニアではないので開発のセンスがなかった。
ビジネスの成長に伴い問題が起こり始めた。
いわゆるLAMP構成のPHPアプリケーションで、100万ユーザーになった頃には毎日のように過負荷な状態になった。
コンテナアプリケーションとAuroraリードレプリカによっての分散をすることで、対応できるようになった。
その後、1,000万人の登録ユーザー数を達成しました。
開発者は必要な機能をツールボックスから選択して、組み合わせることで複雑さを軽減されています。
プラットフォームエンジニアリングのようなお話ですね。
2020年までにさらに2,400万のユーザー登録になり、16の拠点へ展開されています。
コンテナはEKSで構成しています。
マルチリージョンでのデータ同期にSNSとSQSを活用しています。
そして、現在は1億以上の登録ユーザーのサービスになっています。
4億食以上の食品廃棄を防いできました。
グローバルでのシンプルなデータ同期
RDSはデータベースの構築、運用をユーザーに対して非常にシンプルにしました。
最初出会ったときに、今までのデータベース構築やバージョンアップ作業はいったい何だったんだろうと思いました。
Auroraはストレージとコンピューティングを分けたから、サーバーレスのようにオンラインで水平スケールできるんですよね。
リレーショナル・データベースを再発明したのがAurora。
AWSの歴史って再発明(re:Invent)の歴史なんですよね。
新機能のAurora DSQLも小さなマイクロサービス(フロントエンド、Query Processor、Adjudicator、Journal、Crossbar)が集まってその機能を実現しています。
それぞれのサービスはもちろん個別にスケールできます。
SQLを処理するのがQuery Processor、トランザクションコミットの調整がAdjudicator、短期ストレージがJournal、長期ストレージにマージするのがCrossbarです。
ピザを注文するアプリの例で解説されていました。
評価4以上のレストランを探しているので、そのSelect文が実行されます。
SQL実行のためQuery Processorが割り当てられ、トランザクションが開始されます。
この時にタイムスタンプが取得されてからリクエストが送信されます。
データベースはシャーディングされて分散されているので、データの保存先を知るためシャードマップが参照されます。
SQLクエリは特定の行セットのみを取得して、パフォーマンスのボトルネック課題を解決しています。
レストランを見つけたユーザーは次にピザを購入します。
Query Processorがローカルメモリ上でデータの読み取りと書き込みを行い、Adjudicatorがマルチリージョンでの書き込み、更新を単一リージョンと変わらない速度で高速に行います。
AuroraのコンピューティングにもLambdaやFargateでおなじみのマイクロVMのFirecrackerが使われているんですね！
Query ProcessorはFirecrackerで実行されているそうです。
Adjudicatorが、競合や一貫性の確保など書き込み管理をうまくやってるんですね。
ナノ秒クロックで管理されて
、先にコミット送信した側が採用されて、処理中に更新を検知されたほうがアボートされます。
短期ストレージのJournalに書き込まれたコミット済トランザクションが、順序を守ってCrossbarによって長期ストレージに移動されます。
この重要な時間管理を実現しているのが、EC2の時刻設定に使用されているAmazon Time Sync Serviceです。
衛星からの時刻同期が Nitroに伝送されて、Adjudicatorは正確な時間を取得しています。
これらの仕組みをDynamoDBグローバルテーブルでも使用したので、グローバルテーブルの強い整合性のリリースにも繋がりました。
正確な同期時間を扱えるようになったことで、新たなシステムをよりシンプルに実現できました。
CTO Fellowship、AI for Changemakersを設立して、若い企業や組織を支援していく。
シンプルを求めることは重要ですが、それを求めすぎることが制限になってはいけないと知りました。
設計同様に思考も柔軟性が必要ですね。
そして今までの経験は1つの要素として役に立つかもしれませんが、それがすべてではなくこれから学び考えることが重要です。
うまく行ってるときこそ、課題はないか疑問を持って改善を考える。
そして今年もNow Go Build！
現場で活かせるAWSスキル習得はトレノケートのAWS研修で
AWS re:Inventでは、たくさんのワークショップやデモ等をいち早く体験することができます。
それらの体験は体験として終わらせず、ぜひ実務や現場（仕事）に活かしてみませんか？
トレノケートでは、ハンズオンを体験しながらスキルアップを目指すAWS Skill BuilderやAWS研修（認定トレーニング）をご提供しています。実務経験を積んだAWS認定講師のトレーニングは受講者の皆様の満足度も高く、楽しみながらスキルアップを目指すことができます。
「まずはAWSの基礎を理解したい」「AWS認定資格を取得したい」等、目的や役割に応じてAWSのスキルアップを支援いたします。
トレノケートのAWS研修をもっと詳しく知りたい方は、こちらからご確認ください。
AWS研修（AWS認定トレーニング）｜AWS資格取得や基礎習得ならIT研修のトレノケート
