理論、発信、そして行動　今年もビルダーに強いメッセージ

倹約的なアーキテクトとは？　AmazonボーガスCTOが今一番気になるコストとAIを語る

計測し、見える化し、コストを下げていく努力を

　続いて取り上げたのは、メトリクス、つまり計測することの重要性だ。ここでの法則は「計測できないシステムは未知のコストにつながる（Unobserved Systems Lead to Unknown Costs）」。計測することで、初めてコストが見え、コントロールできるわけだ。

　ボーガス氏が生まれ育ったアムステルダムは、1970年代にエネルギー危機に陥った過去がある。中世から美しい街並みを今にとどめるアムステルダムだが、似たような家でも放熱しやすい家と、保温しやすい家で、利用するエネルギーは大きく異なっていたという。そして、省エネを促すためにはメータリングが重要になる。「どれくらいエネルギーを使っているか、見えるようになれば、家に住んでいる人の行動が変わる。継続的に計測することで、行動が変わるということを頭に入れておいて欲しい」とボーガス氏は語る。

　Amazonでは数多くのマイクロサービスのレベルでメトリクスを取得し、集計し、コスト管理に用いている。ボーガス氏はもはや点描のアートにしか見えないAmazon.comのマイクロサービス一覧を披露。全体像を見られる一方、個々のマイクロサービスのコストも得られると説明した。「それぞれのマイクロサービスから数字をとり、積み上げ、トータルで状況を理解できるようにしていかなければならない。分解して、細かい単位でなにが起こっているかを見る必要もある」（ボーガス氏）

Amazon.comを支えるマイクロサービスをビジュアル化

　そして、単に計測するだけではなくコストを下げていく努力が必要になる。実際、Amazonではマイクロサービスレベルでのリクエスト単価は年々下落しているという。「きちんと価値を出し続けているのか理解しなければならない。横ばいや右肩下がりということは投資に対する価値が下がっていることを示してしまう」とボーガス氏は語る。たとえば、Webサイトの遅延を下げるのであれば、チャレンジを行なった上で、きちんと施策で遅延が改善したのかをきちんと把握する必要がある。

　マイクロサービスのシステムは複雑だが、ユーザーはアプリケーションごとのマネジメントが必要だ。「アプリケーションはどのようになっているのか？　コスト、健全性、セキュリティ、パフォーマンスなどをアプリケーションごとに把握し、一元的に観測する。個別の機能のリクエストに落とし、非機能案件につなげ、安定性につなげていくことだ」とボーガス氏は語る。

　こうしたアプリケーションの計測に役立つのが、新たに発表された「My Applications in the AWS Management Console」だ。管理対象のアプリケーションを登録すると、コスト、稼働状況、セキュリティ、性能を一元的に管理し、改善につなげられる。また、新たに発表された「Amazon Cloud Watch Application Signals」では、重要な指標に対するアプリケーションのパフォーマンスを測定し、ダッシュボードを自動的に作成してくれる。これらのツールを用いることで、運用の改善を容易にし、コスト削減にもつなげることができる。

自らのアプリケーションをモニタしてくれるMy Applications in the AWS Management Console

　「メーターを変えれば、挙動も変わる。メーターにはコスト、サステイナビリティも入れてほしい」とボーガス氏は語る。

コストをコントロールせよ　つまみは事業部に持たせよ

　続いての法則は「（コストを意識したアーキテクチャではコスト管理が行なわれる（Cost Aware Architectures Implement Cost Controls）」だ。「ただ、思うだけではダメ、行動しなければダメ。そしてクラウドの中でチューニングできるアーキテクチャを構築し、手元でチューニングできなければならない」と指摘する。

　サービスを構成するコンポーネントをコントロールできるつまみは手元に置かなければいけない。しかし、「つまみは事業部が持つべき」とボーガス氏が指摘する。「技術の人が決めるのではなく、事業部といっしょに意思決定しなければならない。なぜなら、われわれは事業部のためにテクノロジーを活用しているからだ」（ボーガス氏）。

　そして、この意思決定のために必要なのが、アプリケーションの再構成（ReComposition）だという。これはアプリケーションのコンポーネントに優先順位を付けることだ。

　Amazon.comのようなECサイトの場合、最低限必要なのティア1は検索、ショッピングカート、チェックアウトの3つだという。ティア2にあたるのは、リコメンデーション、類似検索、パーソナライズなどは商品を探すためには重要だが、アプリケーションの中核ではないものだ。ちなみにティア2からティア1に重要度が上がったのはレビューで、これがチェックできないと、ユーザーは購買に至らないという。

サービスごとの階層付けを行なう

　こうしたティアを挙げたら、事業部といっしょにこれらのトレードオフを決めていかなければならない。「Amazonはティア1の可用性のためなら、お金をかけるだけかけるだろう。それがなければ事業が成り立たないからだ。でも、ティア2の場合は、そこまでコストをかけない」（ボーガス氏）。こうしてサービスの階層化を行ない、なにが起こっても、つねに予測できるパフォーマンスで稼働すべきものがなにかを決める。また、これらをコントロールするにあたっては、さまざまなノブやスイッチを事業部に提供することが重要だという。

システムの無駄を最適化　危険なのは過去のやり方に固持すること

　デザイン、計測のあとは、いよいよ最適化というフェーズになる。しかし、コストの削減は瞬時には無理で、日々の継続的な努力が必要。「コストの最適化は漸進的に行なわれる（Cost Optimization is Incremental）」だ。

　ボーガス氏が指摘したのは、「小さく考えることの重要さ」だ。「ハードウェアの制約があった時代から、小さく考えることはますます重要になっている。なぜならコストの多くは小さいことに費やされるからだ」とボーガス氏は語る。

　棚卸しをすれば、実はシステムの無駄は数多い。「本当に8Kは必要か？　イメージをリサイズすることは大切か？　もしかしたら、必要でないかもしれない」とボーガス氏は指摘する。実際にGoogleのプロファイラーで調べてみると、システムの無駄がわかる。とあるシステムのコストプロファイルを見てみると、ガベージコレクションは8％に過ぎず、42％をネットワークのコストが締めていたという。

　そして最後の法則は、「挑戦のない成功は思い込みを生む（Unchallenged Success Leads to Assumptions）だ。危険なのは、過去のやり方に固持すること。COBOLの開発者であるグレース・ホッパー氏は、「もっとも危険なフレーズは、『私たちはいつものこのようにやっていた』」と語っていたという。

過去のやり方に固持することを戒めた先人の言葉

　システムの構築にはコストはかかるが、運用にはさらに大きなコストがかかる。そのため、プログラミング言語も過去にとらわれず柔軟に選択すべき。たとえば、ポルトガルで2017年に発表されたレポートでは、プログラミング言語ごとのエネルギー消費量、時間、メモリ消費量がランキング化されており、RubyやPythonはC++に比べてエネルギーの消費量が50倍高いという調査が出ているという。これは一つの指針と言えるだろう。

　セキュリティリスクや学習コストなどもあるため、調査を鵜呑みにすべきではないが、業界のトレンドが急速に変わる現在、保守的な選択をしがちな言語に関してもつねにリサーチを怠るべきではないというのが、ボーガス氏の主張。「なにも新しい言語を学び直せと言っているわけではない。でも、テクノロジー的に考えて、世界は本当に早く変わっているので、つねに学び続け、自分の信条が会っているのかを確認してほしい。マスターJavaプログラマーであれば、ガベージコレクションにどれくらいコストがかかるかを理解すべきだ」とボーガス氏は語り、「おのれの信条を反証せよ（Disconfirm your belief）」というフレーズを聴衆に投げかけた。