こんにちは、クラウド事業部の山路です。
これまでAWS re:Invent 2023のKeynoteについて現地から紹介していましたが、3日目午後以降のKeynoteを現地で見ることができませんでした。
ですがせっかくなので、Youtube動画を見ての感想ですが、残りのKeynoteについても紹介します。
今回はAWS re:Invent 2023のKeynote (Day4) を共有します。
なお、本記事中に出てくる画像は、すべてYoutube動画から引用したものです。
動画はこちらから。
講演開始
発表者はDr. Werner Vogels。
冒頭のムービーにも出てきた "Frugal Architect" (倹約的アーキテクト) が最初のキーワード。コストやサステナビリティを意識してアーキテクチャを構築する。
AWSなどのクラウドを活用することで、オンプレミスに存在した物理的な制約は取り払われました。
一方で考えなければならないことも出てきます。クラウドの利用コストはその一つです。
PBS (アメリカの公共放送サービス) ではオンプレからクラウドに切り替えたのち、CloudFront / S3 / ECSなどのサービスを駆使し、結果的にストリーミングのコストを80％削減することに成功しました。
クラウドの利用コストは、そのままクラウドの計算資源の利用量につながります。コストを下げることは計算資源の節約、つまりサステナビリティにも影響します。
WeTransferの例。アーキテクチャを見直し、二酸化炭素排出量の推測と削減につなげました。
ここからはFrugal Architectの話。デザイン/計測/最適化の3つのカテゴリに分かれます。
デザインの1つ目、コストは非機能要求である。
非機能要求と言えばセキュリティや可用性などが思い浮かびますが、
コストとサステナビリティもそこに加えるべきです。
Amazon S3サービスの開発時、当初はデータ転送量とストレージ利用量のみをコストに計上することを想定していましたが、実際に顧客に提供したところ、リクエスト数という別の指標を追加すべきことに気づきました。特に新しいサービスを開発する際は、どんなコスト体系が適切か事前に知ることは困難です。
ここで重要なのは、デザインのあらゆるステップでコストを意識すること。
デザインの2つ目、ビジネスコストに見合ったシステム。
ビジネスをサポートするのがシステムです。そのシステムがビジネスによる収益を圧迫するほどコストがかかるものでは意味がありません。
インフラストラクチャの場合、多くは規模の経済が働き、スケールするほど収益は増加するはずです。
一方でサービスの設計がうまくない場合、想定以上の利用量が発生し、コストが一気に増加する場合もあります。
ビジネス上の決定とテクノロジー上の決定が調和がとれていることを常に確認してください。
AWS Lambdaを開発しているとき、セキュリティ・分離・コストの3つを満たす方法がなかったため、コストをある程度犠牲にすることを決定しました。
その後、Firecrackerの開発により、より効率的にリソースを利用できるようになりました。
アーキテクチャは時間によって変化するため、進化可能なアーキテクチャを構築する必要があります。上記Lambdaの例のように。
もしもコストを度外視する形でシステムが構築されている場合、いつかはその負債を支払わなければなりません。
デザインの3つ目、アーキテクチャは常に一連のトレードオフである。
ここで1人目のゲスト、NubankのCat Swetelさん。
PIXと呼ばれる新たな送金アルゴリズムを提供した結果、想定以上の速度で利用量が増加し、コストと安定性のバランスをとるための決断を迫られました。
これを解決するため、いたずらにリソースを追加するのでなく、システムそのものを安定したものにすることで解決しました。その一つは長期間停止するマイクロサービスに対し、Z Garbage Collectorと呼ばれるガベージコレクションを適用することでした。
さらにデータベースとキャッシュの戦略も見直しました。
結果として、システムの効率向上とコスト削減の両方を達成しました。この成果に会場からも拍手。
ビジネスと協力して優先度を調整することが大事。
デザインのパートはこれで終了し、次は計測。
システムに観測されていない場所があれば、未知のコストが生まれます。
話は登壇者の故郷へ。まったく同じつくりの2つの家でエネルギー使用量が異なるものがあり、その理由は利用メーターが目につくところにあるかどうかでした。
Amazon.com でどのようにコストを計測しているかの話。マイクロサービスアーキテクチャを採用する同企業では、ある1つの機能を呼び出すことで数十のマイクロサービスが呼び出される可能性があります。それらがどのようにコストがかかるか、計測する必要があります。
こちらがAmazon.comのマイクロサービスの全プロットしたものだそう。
コストを理解することが大事。ただそれが困難な場合もあります。これを解決するため、
新サービス、AWS Management Console myApplicationsの発表！
続いてAmazon CloudWatch Application Signalsの発表！EKSに関するあらゆるメトリクスを1つのダッシュボードから確認できるようになります。
メーターを定義することで、それを継続的に監視した結果、システムとコストがどのように変化するかわかるようになります。
計測の2つ目、コストを意識したアーキテクチャにはコストの管理が必要です。
システムの一部にアクセスなどによって負荷が集中したとき、その一部を切り離して調整できるようにする必要があります。
アプリケーションを分解し、どの部分がより重要か、ティアを分けることが重要
ティアを決定し、常に稼働し続けなければならない部分がどこにあたるかを考えることが大事。
最後に最適化の話。
コスト最適化は漸進的です。
まずは不要なサービスを止める、サイズを変更する、削減するなどのことから始めます。
プロファイリングの話。Amazon CodeGuru Profilerを使うと言語ごとの？プロファイルが可能です。
プロファイルにより、コストのかかるポイントが明らかになり（ここではネットワーク）、これを解消するためにコードを修正することができます。
最適化は継続的に行う必要があります。
最適化の2つ目は、トライすること。
いつも同じやり方を続けることは危険です。
例えば、開発言語によって利用するエネルギー量が異なるという研究結果も出ています。Rustのようにエネルギー使用量が少ない言語に切り替えることもコスト減につながります。
エゴを横に置くことも重要です。
これでFrugal Architectのパートは終了。
2本目のムービー。1本目もそうでしたが、映画マトリックスのオマージュシーンがたくさん。
未来を予測するには現在をよく見ることも重要、とはじめてから、コンピュータに関する歴史の紹介。
歴史の積み重ねから、AIが生まれました。
ただし、必ずしも最新の生成AIをすべてのシーンで使わなければならないわけではありません。古き良きAIの例を紹介。画像認識による分類などで課題を解決。
2人目のゲストはThornのDr. Rebecca Portnoff。
虐待を受ける子供をより素早く見つけるため、動画データから該当するものを高速で見つける機械学習システムを開発。
AWS Marketplaceでも利用可能。
良いデータが良いAIにつながる。この辺りは今までのKeynoteでも出てきた話。
AIモデルの作成方法。扱うデータによってはKaggleにデータセットがあり、用意されたモデルにデータを与え学習し、出来上がったモデルはAPIを通じてアプリケーションから呼び出せます。
登壇者が実際に開発したモデルはGitHubから利用可能です。「私ができたんだから、あなただってできるはず」。
生成AIとともに開発する。例えばCodeWhispererと共同で作業をするなど。
ここでAmazon Sagemaker Studio Code Editorの発表。
Amazon Qの話。CodeCatalystやIDEでも使えるようです。
AWS Application Composer in VSCodeの発表。
builderになるのに、今ほど良いタイミングはありません、と繰り返し強調。Now Go Build。
re:Playの案内。今年はMajor Lazerが登場しました。
最後のムービー。「CI/CDからコンテナイメージをスキャンしたいけどできなかった」→「いや、今ならできると思うよ」
からの新サービス発表でクロージング。
さいごに
コストを意識すること、そしてbuilderであることの重要性を紹介するKeynoteとなりました。特に後者のパートではポジティブなメッセージも多く、これはほかのKeynoteとも共通しているように見えました。
また普段インフラエンジニアとして業務をする身として、コストの話は業務として、builderの話はエンジニアとしての将来に向けて、どちらも響く内容でした。ポジティブなメッセージも相まって、何かをやるにはちょうど良いタイミングになりそうです。
さて、Keynoteの紹介は今回で終了となりますが、明日以降もAWS re:Invent2023の内容を共有していこうと思います。
