アーキテクチャの知見を惜しみなくシェアしたre:Inventのエンジニア必見講演

複雑なシステムをシンプルに　Amazon CTOボーガス氏が語る6つの学び

　12月2日～6日に開催されたAWSのフラグシップイベント「AWS re:Invent 2024」。最後の基調講演に登壇したのは、Amazon CTOのヴァーナー・ボーガス氏。Amazonを支えるテクノロジーやアーキテクチャについて解説するre:Inventで目玉となるエンジニア向けの内容だが、今年のテーマは「複雑性」。システムに忍び寄る複雑性に対応するべく、シンプルさをいかにキープするかの哲学を語り尽くした。

Amazon CTOのヴァーナー・ボーガス氏

21世紀のアーキテクチャを実現する4つの要件

　Amazonのエンジニアプリンシパルである「2ピザルール」を題材としたコミカルな動画の後に登壇したボーガス氏は、冒頭で自らのキャリアを振り返る。20年前、当時45歳だったボーガス氏は、学問の世界を離れて書店で働くことになった。書店というのは、もちろん世界最大の書店であるAmazon.comのことだ。「学び、学び、学びの20年間だった。お客さまに対応することで、学びが得られた」とボーガス氏は振り返る。

　ただ、当時はCTOがどのような仕事をするべきかはわかってなかったという。それはAWSの基盤を構築した前任者も同じだった。「でも、わからないからやってみようと思った。それが20年前の話。CTOの役割を初めて開発するようなものだった。原則や次世代のアプリケーションはどうあるべきかを考えるようになった」とボーガス氏は振り返る。2012年に生まれた21世紀のアーキテクチャが、「コントラーラブル」「レジリエント（回復力）」「データドリブン」「アダプティブ（適用力）」の4つだ。

2012年に生まれた21世紀のアーキテクチャ

　コントローラブルを実現する要素は、「できるだけ小さく作り、緩やかに結合された、ステートレスなビルディングブロック」「アプリケーションとプロセスの自動化」「ビジネスレイヤーでシステムを制御させる」「コストを考慮したアーキテクチャ」から構成される。「モノリスとマイクロサービスの間で、特定のシナリオのためになにかを作る。こういった議論は事業部といっしょに考えることが必要。テクノロジーを考えるだけでは十分ではない。お客さまのために作らなければならない」とボーガス氏は語る。

　また、レジリエントについても考える必要があった。「すべての物事は失敗する。でも、すべての失敗を計画すれば失敗することはない。とにかくプランすることが重要」とボーガス氏。もちろん、進化をし続けること、変化に順応することなども大事だ。「2012年にはさまざまな目的に特化型のデータベースが存在したし、いろいろなものが十分ではなかった」（ボーガス氏）。多くの選択肢の中から、未来を見ながら、最適なものを選び、変化の激しい市場に対応してきたわけだ。

システムに忍び寄る「複雑さ」からは逃れられない

　システムを構築する際には、つねに複雑さというものがつきまとう。その複雑さをコントロールすべきというのがボーガス氏の持論。「物事は複雑になりがち。より多くの機能を提供すると、規模が必要になるし、セキュリティの問題にも対応しなければならない。でも、AWSのシステムはとにかくシンプルを目指してきた」（ボーガス氏）。

　ボーガス氏の今回のテーマは「SimpleとComplexity」を組み合わせた「Simplexity」だ。これは「複雑なものをシンプルに作る」という原理で、複雑性を管理し、監視しなければならない。テクノロジーの変化やアーキテクチャの監督不足で、意図せず複雑性が忍び込んでしまう場合もある。この複雑性に目をつぶると、システムのパフォーマンスは低下する。そのため、まずはこの複雑性を認識することが重要になるという。

　意図しない複雑性が忍び込む兆候は、いくつもある。単一のモノリスから複数のマイクロサービスへ、そしてシェーアードサービスのインフラへと進化を続けてきたAWSにおいては、複雑性が忍び込むと、イノベーションの進化が遅くなってしまう。エスカレーションが多くなり、デバッグに時間をとられ、コードが増え、定型のパターンがイレギュラー化。あらゆるところで依存性が発生し、結果差別化につながらない作業が発生してしまう。「こうした複雑性からわれわれは逃れることができない」とボーガス氏は語る。

複雑性はいくつもの兆候が現れる

　複雑性について誤った理解をしてしまう可能性もある。たとえば「コンポーネントの数が多い」ことは必ずしも複雑性にはつながらない。ボーガス氏は、自転車の構造を例に複雑性について説明したコルノ・マッカーシー氏の例を披露する。

　一輪車はシンプルで、コンポーネントの数も少ない。一輪車に乗ることができれば、方向転換も容易にできるが、実際に乗りこなすにはスキルが必要になる。一方、三輪車は安定度が高く、乗るのも簡単だ。しかし、方向転換の柔軟性は高くない。こうして考えると、二輪車は乗りこなすのも容易で、柔軟性も高い。自転車としてもっとも理想的という結論になる。「三輪車より乗るのは難しいが、一輪車よりは絶対に簡単。二輪車はコンポーネントも多いが、全体的で見ればもっともシンプルだ」とボーガス氏は指摘する。

二輪車はコンポーネントも多いが、運転は楽で、全体から見るともっともシンプル

「世界にデザイン力を」目指したCanvaのシステムスケール

　「シンプルさには規律が必要」とボーガス氏は訴える。シンプルさを保ちながら、複雑性を追加している会社として紹介したのが、CanvaのCTOであるブレンダン・ハンフリー氏だ。

CanvaのCTOであるブレンダン・ハンフリー氏

　Canvaは「世界にデザイン力を」という野心を掲げ、10年前に設立された。スキルレベルに関係なく、ビジュアルコンテンツを作成できるプラットフォームを構築しており、現在世界190カ国、2億2000万人以上のユーザーが利用している。Canvaへの秒間リクエスト数は120万以上。管理対象のメディアは162PBを超え、毎日230TBのデータが追加されている。また、作成されたデザイン数は300億。これは450以上のデザインが毎秒作成されている計算になるという。

　会社が創業された2014年当時、バックエンドのエンジニアは数人しかおらず、1つの部屋で作業をしていた。「冬には（お金を）暖房に使うか、外部モニターに使うかを選ぶしかなかった。もちろん、われわれはモニターを選んで、寒さに適応した」とのことで、指先だけを抜けた手袋で寒さにこごえながら作業をしていたという。

　当時考えたのは、いかに速くシステムを作り、市場に展開するか。そして速くアーキテクチャを構築し、スケールさせるかだった。マイクロサービス的なものが必要なのはわかっていたため、最小コンポーネントのモノリスを分解できる形で作り、スケールさせる前提でアーキテクチャを設計した。データベースはRDSの単一のMySQLだったが、スキーマ設定はエンティティ間の関係を厳密に分離し、データベースの拡張も容易にした。

　しかし、急速に成長するサービスにあわせ、巨大化したMySQLをDynamoDBに移行するのは困難だったという。「MySQLの容量を限界まで引き延ばすには、データベースの奥義のようなテクニックが数多く必要になった」（ハンフリー氏）とのこと。たとえば、ゼロタイムスキーマの移行を妨げるために、外部キーはすべて削除。ジョイン処理がとても高価になったため、スキーマの大部分を非正規し、カラムもJSONテキストに変更した。

MySQLを延命させるためにさまざまな“魔術”を駆使

　こうしたMySQLの延命策の結果、DynamoDBへの移行を実現。現在管理しているアイテムは930億件で、1日9000万件のペースで成長している。「アーキテクチャ内で適応する抽象化について真剣に考え、パワフルに、継続的に、コンポーザブルにしている」とハンフリー氏は語る。

　現在CanvaはアプリのSDKとコネクトAPIを提供し、ユーザーのシステムから利用できるようにしている。こうして多くのエンジニアがCanvaを基盤として活用し、すでに300ものアプリがマーケットプレイスに登録されているという。「80億人が使えるようにしたいが、その道のりの1％しか達成していないとわれわれのCEOは言っているが、私の計算では2.72％だ。これから10年、その先が楽しみ」と講演を締めた。