クラウド事業部の原口です。

AWS re:Invent 2023。AWS CTO の Werner氏のキーノートが非常に心に残ったのでレポートしたいと思います。Werner氏のキーノートは毎年独自のストーリー展開で語られ非常に面白くて深く聞き入ってしまいます。今回はマトリックス風味w

キーノートで語られた「Frugal Architect」を再検討した7原則について個人的に落とし込んでいきたいと思いましたので、まとめながら記述していきたいと思います。

The Frugal Architect の7原則は以下のページより見れます。

The Frugal Architect
https://thefrugalarchitect.com/

[設計]

第1条 コスト(とサステナビリティ)を非機能要件にする

非機能要件はシステムの運用を判断するための基準を指し、例えばアクセシビリティ、可用性、スケーラビリティ、セキュリティ、移植性、保守性、コンプライアンスなどがあります。よく見落とされがちなのがコストです。企業は、設計から開発、運用までの各段階でコストを考慮しなかったり、適切に計測しなかったりするために失敗することがあります。収益を超えるコストはビジネスにリスクをもたらします。

非機能要件に、コストとサステナビリティを追加するべきという強いメッセージがありました。
コストとは何かという部分も考えさせられます。システム開発においてどこに注力をするか、つまりリソースの管理という事と同義であるように個人的には捉えました。

リソースを割いた結果(=コスト)に対して収益が間に合わなければ当然ビジネスでは失敗です。

第1条を要約するとWerner氏は「あらゆる段階でコストを考慮せよ」と言っていました。

「運用性に優れたソフトウェアは運用を無視した開発からは生まれない。」
これは僕がAWSでの設計や提案をする上で最も意識して考えている事です。
この話はこの格言とつながるところがあると感じてしまい、のっけから話にのめり込んでしまいました。

第2条 ビジネスとコストを調和させるシステムの持続性

システムの耐久性は、そのコストがビジネスモデルとどれだけ調和しているかに依存します。システムを設計・構築する際には、収益源と利益を考慮する必要があります。重要なのは、利益を得るための要素を見つけ、その要素に基づいてアーキテクチャを構築することです。

システムを持続させるには負債を返済せよ。
ビジネスの決定と技術の決定を同じラインで考えると、技術的負債はビジネス的問題でもある。
そうやって負債を返していく事が調和であると言っていました。

例としてAWSにおいてT2インスタンスからFirecracker microVMへの移行であったりAWS Lambda の価格戦略などの説明が行われました。しっかりと負債を返済し進化しているのがすごい。

ビジネスの決定と技術の決定が合う事について、もっと本気で取り組んでいかないといけないと感じます。ビジネスのスケールに伴って、利益はあがり、コストは抑えられるようにならなければならない。

でも負債返すの大変なんだよなぁ。これは技術的な観点でもそうだし、ビジネスへの説明もそう。。でもそれらの放置が破壊への道につながる事も確か。

第3条 アーキテクトはトレードオフの連続

アーキテクチャでは、あらゆる決定にトレードオフが伴います。コスト、回復力、パフォーマンスは、しばしば相反する非機能要件です。

優先順位に寄り添おうという事。

「Frugal Architect」は単なる支出を節約しないさい、というわけではなく価値を最大化できる箇所に投資をすることも重要と言っています。

これらについてNubankという会社が9,000 万人の顧客が 2022 年に手数料を80 億ドル節約したという事例の紹介が行われました。

トレードオフのこの法則は個人的な業務に照らし合わせると、顧客の要望からアーキテクトする事おける「現実解」とも近しいものを感じます。

[計測]

第4条 計測されていないシステムは未知のコストを生む

注意深い観測と測定がなければ、システムの運用コストの実態は見えないままです。視界から隠れたユーティリティメーターのように、見えないことが無駄な習慣を助長します。メーターをより目立つようにすることは行動を大きく変える可能性があります。

「測れないものは管理できない」というあたりで、そもそも測れないコストは何だろうと自分の中で思考が脱線してしまったのですが。

こちらの文脈で新しいサービスであるmyApplicationsと、Amazon CloudWatch Application Signalsが発表されました。これらの新機能はコストとサステナビリティの計測を強化することを目的としているそうです。

「コスト目標」があればより持続可能な実費を削減できるというのは本当その通りで、これは円安などでコストに関する目がシビアになった時に改めて目を向けた際に実感しました。
普通に動いていると思ってたシステムでもまだまだ削減の余地があったのはショックでしたね。

これらの削減についていつでも確認できるよう「メーターを定義せよ」と言われていましたが、計測できるシステムを用意せよという認識でいいのかなと思います。

第5条 コスト管理と調整ができるアーキテクチャ

節約志向のアーキテクチャの本質は、堅牢なモニタリングとコスト最適化の能力の組み合わせです。よく設計されたシステムは、改善の機会に対応することを可能にします。これを実現するためには、アプリケーションを調整可能なビルディングブロックに分解する必要があります。

Amazonのサイトを例に出しての説明。
Amazonは機能ごとにTierを定めていて、Tier1の障害に対しては最もコストを払うところ、としていて、他のTierが落ちてもTier1だけは必ず落ちないようにしないといけないようにしているのだとか。こういった重要度に応じてコンポーネントを階層化している例が示されました。
また、過去Tier2からTier1へ移した機能は「レビュー投稿」とのこと。

AWSにおいてはamazonショッピングサイトでの事例が出てきますがどれも興味深いです。

一見するだけで「マイクロサービス化」されてることで重要度に応じたコンポーネットへの注力が可能となっているわけで、マイクロサービス化の導入がこれらのFrugal Architectの原則に従った結果生まれたものなのだなと考察でき、非常に面白いです。

素人的に見てTierを分ける事で各コンポーネットにおけるコスト戦略の取り方は変わってきますよね。オンデマンドにするのか、スポットにするのか、RIにするのか、みたいな。

[最適化]

第6条 コストの最適化は段階的なものである

コスト効率の追求は継続的な旅であり、デプロイメント後もシステムを定期的に見直し、最適化を段階的に改善する必要があります。鍵となるのは、継続的に問いかけ、より深く掘り下げることです。プログラミング言語はコードのパフォーマンスを分析するプロファイリングツールを提供していますが、これらはセットアップと専門知識を必要としますが、詳細な分析を可能にし、ミリ秒単位の変更につながる可能性があります。小さな最適化のように見えるものでも、規模が大きくなると大きな節約につながります。

Vogels 氏は、コスト効率の追求は継続的な旅であると言っていました。

実際のところコストの部分は小さなレベルの部分に集中していた、といった文脈から実例の説明が続きます。ネットワーク部の1%の失敗時の例外処理に40%以上のCPUを使っていた的な説明があったように思います。

当時は専門的な知識でこれらの評価を行なっていたが、現在、CodeGuru Profiler は、機械学習アルゴリズムを使用して、最もコストのかかるコード行を見つけ、効率を向上させ、CPU ボトルネックを取り除く方法を提案するのに役立ちますといった例や、Gravitonを使用することなどが紹介されていました。

第7条 挑戦なき成功は思い込みを生む

ソフトウェアチームが大きな失敗や障害に直面せずに重要な成功を収めると、自己満足が生じることがあります。成功に導いた方法、ツール、実践への過度な自信を持つ危険な傾向があります。

まぁ現場でよく聞きますし言っちゃいますよね。。「現行踏襲で！」「前回と一緒で！」。けっこうグサッときましたね。

ちなみに「もっとも危険な英語は”私たちはいつもこの方法でやってきました”」と表示されたスライドは会場で結構な盛り上がりを見せていました。

どうしても初期のリリースをゴールと捉えがちで見逃される事が多いですが、初期の開発よりもリリースしてからの運用の方がコストはずっと大きい。

その中で自己満足せず、常に改善する方法を探すということの重要性が説かれました。
最後に「自分の信念を否定せよ」という強いメッセージでまとめられました。

実際のキーノートは2時間ほどありましたが、英語能力が低く解像度が低かったため、日本に帰国後あらためて訳しながらまとめてみました。

Amazonのように巨大な企業でクラウドの第一人者となったAWSサービスについて、CTOが「コスト」について基調講演でお話しているのは新鮮ですね。何よりも顧客のビジネス、AWS利用に対して言ってるわけで面白いです。

こうしてまとめると味気ない内容に見えるかもしれませんが、実際のキーノートでは語り口調が情熱的であり、ジョークも挟み、あらゆる内容における事例や経験が余すことなく紹介されており非常に楽しいものですので、ぜひぜひ動画もご覧ください。

来年のTシャツも楽しみにしています！