"A Conversation with Amazon CTO Werner Vogels"について

Amazonの最高技術責任者（CTO）であるワーナー・ヴォーゲルス氏と、Mentoのエンジニアリング担当副社長であるケビン・ボール氏（Kball）との対談がポッドキャストで公開されています。この対談では、Amazonの初期、AWSの誕生、**「フューガル・アーキテクト（Frugal Architect）」**の原則、コストとビジネスの連携、技術的負債など、幅広いテーマが議論されています。以下に主要な点をまとめます。

1. ワーナー・ヴォーゲルス氏の経歴とAmazon/AWSの歴史

ワーナー・ヴォーゲルス氏（Werner Vogels）は2004年にAmazonに入社する以前、コーネル大学で分散システムとスケーラビリティに焦点を当てた研究科学者として活動しており、これらの概念は後にAWSの設計に影響を与えました。彼は20年以上にわたりAmazonの技術的ビジョンを形成する上で極めて重要な役割を果たし、オンライン小売業者からグローバルなクラウドインフラストラクチャプロバイダーへの移行を導きました。

Amazonの創業者であるジェフ・ベゾスは、インターネットに魅了され、他のどこにもできないことを実現するために書店を始めたに過ぎません。1994年当時、Eコマースに関する書籍やプラットフォームが存在しなかったため、Amazonはその後の技術的要素を基本的に全て自前で発明する必要がありました。

2. AWSの誕生と課金モデルの変革

AWSの開始以前、Amazonは固定容量の問題に直面していました。容量が不足すれば顧客が不満を抱き、多すぎればCFO（最高財務責任者）が不満を抱くというジレンマがありました。特にトラフィックが通常の4倍になるブラックフライデーは悪夢であり、制約が創造性を生み出すものの、困難な時期でした。

AWSは、この固定されたハードウェアの制約から解放され、状況を一変させました。ヴォーゲルス氏がAWSで最も誇りに思っているのは、技術革新だけでなく、課金モデルを変えたことです。

• 従量課金モデル (Pay-as-you-go): 以前のIT企業では前払いが必要でしたが、AWSは使用した分だけ支払うモデルを導入しました。これは当時革新的でしたが、自宅の電気代を払うのと同じくらい自然なモデルだとヴォーゲルス氏は述べています。

• この新しいモデルにより、エンジニアは自分たちの選択がコストにどう影響するかを考えるようになりました。

3. フューガル・アーキテクト（Frugal Architecting）の原則

2012年頃、クラウドへの移行とイノベーションを優先する企業は、コストを二の次にしがちでした。しかし数年前から、財務部門がデジタルインフラのコストに懸念を抱き始めたため、ヴォーゲルス氏はこのトピックを再考し、経験に基づいた確固たるアドバイスを提供するに至りました。これが「フューガル・アーキテクト」です。

「フューガル・アーキテクト」とは、安くあげることを意味するのではなく、投じた費用に対して最大の価値を得ることを意味します。

A. 設計段階でのコストの組み込み

• 非機能要件としてのコスト: 設計の初期段階で、コンプライアンス、セキュリティ、アクセシビリティといった非機能要件と同様に、コストを意識する必要があります。

• サステナビリティの指標: 現状、特定の計算におけるCO2排出量を明確に示せない限り、コストはサステナビリティの良い代理指標となるとされています。費用が多いほど、使用したリソースが多い可能性が高いためです。

B. ビジネスとの連携とコストのアライメント

• ビジネスへの深い関与: エンジニアリング組織はビジネスと密接に関わるべきです。IT部門が独立した場所で要件リストを受け取り、構築するというのは「ナンセンス」であり、エンジニアはビジネスパーソンと同じ部屋にいるべきです。

• 収益モデルとの一致: テクノロジーのコストが拡大する方向と、会社の収益がもたらされる方向が一致していることを確認する必要があります。例えば、従量課金モデルでコストが増大するシステムを、収益がサブスクリプションモデルに基づいているビジネスで運用すると、ビジネスリスクが生じる可能性があります（無制限パッケージで利用が爆発的に増加したMiFiデバイスの例）。

C. トレードオフとアプリケーションの階層化

• 費用対効果の測定: エンジニアリングの努力がビジネス的リターンを生むかどうかが重要です。例えば、ウェブページの応答速度を1.5秒から1.1秒に改善しても、それ以上の改善はコンバージョン率に影響を与えず「単なる多忙な作業で無益」となる場合があります。

• ティアによる分類: アプリケーションを複数のティア（階層）に分解し、ビジネスの観点からそれぞれの信頼性要件を決定します。

  • Tier 1（必須）: 検索、カート、決済、レビューなど、ビジネス上常に動作する必要があるもの。99.9%の可用性が求められる場合、コストは高くなります。

  • Tier 2（重要）: レコメンデーションなど。5分程度オフラインになっても対応可能であれば、それに応じたコストをかける。

  • Tier 3（あれば良い）: ベストセラーリストなど。1時間オフラインでも問題ない可能性があり、それに応じてコストを抑える。

• エンジニアは全てを最高レベルの可用性（4ライン可用性など）で構築しがちですが、これはビジネスの観点からはコストがかかりすぎる場合があります。

D. 測定、技術的負債、プログラミング言語の選択

• 可視化の重要性: 測定なしでは「盲目飛行」になります。コストに関する測定結果を皆が見えるようにすることは、行動を変える強い動機になります。エネルギーメーターを地下ではなく廊下に設置したことで電力使用量が減少したという1972年の石油危機の例が挙げられています。開発環境を使わない時はシャットダウンするなど、コストが可視化されると最適化が進みます。

• 技術的負債の返済: 開発初期にどれほど優れていても、技術的負債は必ず発生し、返済しなければ信頼性、コスト、パフォーマンスにおいて将来的に問題となって跳ね返ってきます。これは家の住宅ローンに例えられます。

• 戦略的な技術的負債: イノベーションのために意図的に技術的負債を負うこともあります。Amazon Freshでは、アジャイルなプロトタイピング環境としてRuby on Railsで開始されましたが、スケールアップの際には書き直す必要があることが初日から分かっていました。

• プログラミング言語の効率: サステナビリティやコストが重要である場合、使用するプログラミング言語を再評価すべきです。PythonやRubyはRustに比べて75倍も非効率的であるため、Amazonでは現在、JavaからRustへの大規模な書き換えが進められています。Rustは学習が難しいものの、非常に高速で優れたセキュリティ特性を提供します。

• ヴォーゲルス氏は、海軍少将のグレース・ホッパーの言葉「英語で最も危険な言葉は、『我々は常にこのやり方をしてきた』である」を引用し、現状維持に安住しない姿勢の重要性を強調しています。

4. 拡張可能なアーキテクチャ（Evolvable Architectures）

AWSのようなサービスでは、一度ローンチすると顧客がその上にビジネスを構築するため、簡単に停止したり、APIの提供をやめたりすることはできません（「APIs are forever」）。

• 進化の組み込み: ソフトウェアは数年後には全く異なるアーキテクチャで稼働していると認識しつつ、顧客にとっては永久に稼働しているように見えるように構築する必要があります。Amazon S3は当初6つのマイクロサービスから始まりましたが、現在では200以上になっていますが、サービスを停止することなく進化しました。

• 組織構造の活用: 進化や技術的負債の解消を進めるために、小規模なチームを組織して、既存のアプリケーションの特定の部分を新しいサービスとして切り出し、書き直す作業を担当させることが効果的です。

• 非自明な思考: システムの安定性のために、直感的には非効率的に見える設計（例：一定の作業負荷を維持する「Constant Work」）を採用することもあります。

ヴォーゲルス氏は、アジャイルなビジネスと技術の連携、そして故障への露出を最小限に抑えるためのサービスやセルへの分解（分解の原則）が、進化の鍵であると結論づけています。

おわりに

Amazonの最高技術責任者（CTO）であるワーナー・ヴォーゲルス氏がポッドキャスト"A Conversation with Amazon CTO Werner Vogels"の中で述べた内容をまとめました。
「今回の情報が役に立ったよ」という場合は、「スキ」を押していただけると嬉しいです。