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

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

システムは進化し、複雑性は増す　気がついたときにはゆでガエルになる

　時間が経てば複雑になってしまうシステムをシンプルに保つにはどうすればよいか。ボーガス氏はいくつもの「学び」を紹介した。

　シンプルなアプリの背後で起こっている複雑な変化。「進化は基本だ。変化はつねに起こっている。なにも変わらないというのは幻想だ。デジタルシステムもそうだ」とボーガス氏。1960年代に発表されたソフトウェアの進化に関するリーマンの法則を引き合いに、「ソフトウェアに新しい機能がなければ、お客さまは品質が下がっていると感じてしまう」と指摘する。

　ここでボーガス氏がもっとも重要と挙げる1つ目の学びが「進化する可能性（Evolvability）」だ。たとえば、2006年に登場したAmazon S3は18年経った今まで進化を続けつつ、複雑性に耐え続けている。「毎年新しい特徴を付け加えている。新しい機能を提供し続け、お客さまに妥協してもらう必要もなかった」（ボーガス氏）。

年々進化を続けていったAmazon S3

　年々高まっていく複雑性に対応すべく、AWSはハードウェアインフラの刷新にも手を付けた。複雑化したネットワークを仮想化し、セキュリティや処理のオフロードを可能にするチップをベースにAWS Nitro Systemを構築した。「進化できる環境を作ること。そのためには複雑性を管理できる事前環境が必要だった」とボーガス氏は語る。

　「複雑性は気がつかないうちに増大する」。セッション中に何度も飛び出すこの警告を気づかせるべく、ボーガス氏はゆでガエルの事例を引き合いに出す。「沸騰したお湯の中にカエルを入れると、カエルはすぐにそこから飛び出そうとする。でも、徐々に温度を上げると、その兆候に気がつかない。危険を感じたときは、もう逃げられない」。ちょっとした兆候を見逃すと、複雑性は増し、把握することすら困難になるという。

気がつけばゆでガエルになる

　例として挙げたのは、クラウドの監視を行なうAmazon Cloud Watchになる。「現在は巨大なサービスになっている。何兆ものメトリクス監視があり、エクサバイトというログが入力されている。AWSにとっても不可欠なサービスになっている」とボーガス氏。ローンチしたときは単純なサービスだったが、監視するメトリクスが増え、新しい機能が実装され、どんどん大きくなり、複雑性が増してきた。

　ここで登場する複雑性に対応する2つ目の学びが「複雑性を小さなピースに分割すること」だ。システムをディスアグリゲーション（分割）し、コヒージョン（凝縮性）を高め、APIを定義する必要がある。現在はメトリクスのストア、発見、ストリーム処理、インサイト、アラーム、アノマリ検知など機能ごとに分割・疎結合化されており、各コンポーネントが独立性を保って更新できるようになっている。

　「初めにシステムをどのように分割するのか、どれくらいの小さいコンポーネントにするのかを考える必要がある。システムを小さなブロックのような形にすることで、進化できるようになり、機能を向上させることができる。ライブラリのような形でプログラミング言語も利用できる」（ボーガス氏）。

アーキテクチャと組織を適合させる重要さ　フォーカスとオーナーシップ

　どれくらいの大きさにするのかは2つのオプションがあるという。新しい機能を実装するために今のシステムを拡張するか、新たなマイクロサービスを迅速に構築するかだ。しかし、後者の場合は管理が必要になり、サービスも増えすぎてしまう。3つ目の学びであるアーキテクチャと組織という観点でそのヒントを語ったのは、Amazon S3を担当するAWSエンジニアのアンディー・ウォーフィールド氏だ。

Amazon S3を担当するAWSエンジニアのアンディー・ウォーフィールド氏

　ウォーフィールド氏は、「18年前にスタートしたS3は、私のキャリアの中でもっともクールなもの。長らく1つのチームでS3を進化させ続けてきたが、システムはどんどん大きくなる。チームも大きくなる。われわれがベストを実現するには、2つ考えなければならないことがある」と説明する。

　1つ目はつねに組織でシステムにフォーカスを当てることだ。同氏が聴衆に見せたのはトレーラーとトレーラーを牽引するトラクターだ。自走可能なトラクターはシャーシを後ろに連結し、貨物を載せたトレーラーを牽引することができるが、荷物を乗せれば乗せるほど、トラクターの運転が難しくなる。システムをトレーラーとし、トラクターを運転するドライバーがチームだとすると、これは大規模な分散型システムを構築するためのソフトウェア開発と似ているという。「引っ張れば引っ張るほど重くなり、複雑さは増大する。牽引するにはパワーが必要になる。これは組織と似ている。複雑なものでも、組織でしっかりフォーカスを当てることが重要」とウォーフィールド氏は語る。

自走するトラクターと牽引されるトレーラー

　「Amazon S3の開発はうまくいっていたが、なにかしくじるのではないかとつねに恐怖心を持っていた。うまくいっているときほど、見落としているものがあるのではないか考えるものだ」とウォーフィールド氏。こうした中、S3のチームも拡大したが、組織としてとにかくシステムにフォーカスをし続け、経験の浅いエンジニアでもきちんと仕事ができるよう体制を構築した。また、ほかのチームと膝をつき合わせて議論を続け、他チームからも学びを得た。脅威をつねに感じながら、改善を続けたわけだ。「とにかく問題を解決するには、現状に甘んじない。同じことをやり続けないこと」（ウォーフィールド氏）

　2つ目の提言は「オーナーシップ」という考え方だ。「これはAWSでも、Amazon全体でも根付いてことだが、説明は難しい」と語るウォーフィールド氏だが、「自らのキャリアの中で、好きなこと、気にしていることに取り組んだとき、どれだけ品質を上げるためにがんばったかを考えてほしい。逆に『やりなさい』と言われてやったこと、メリットや成果がわからなかったことについて考えてほしい。この2つの違いがオーナーシップの有無」と説明する。うまくやっているチームは、前者にあたるオーナーシップを巧妙にドライブしていうという。

　このオーナーシップは、日本語で言う所有感よりも、自律性を意味するようだ。ここにはチームに幅広さやサポートを感じさせる「エージェンシー（Agency）」から構成される。「これはどのようにやるかを提示するのではなく、問題を提示し、それを説明し、チームを信頼することで、所有感を提供することだ」とウォーフィールド氏。もう1つは「緊急性（Urgency）」を感じさせること。「期待しないことが起こった際に、速く動き、チームに問題を解決させる。そして、サポートを提供して、成果を出すことだ」と説明し、ボーガス氏にバトンを戻した。