[レポート]Well-Architected ブートキャンプ #AWSSummit

はじめに

AWS Summit Tokyo 2016 の会場に行われた Well-Architected ブートキャンプ に参加してきましたので、レポートします！

トレーニングの概要

re:invent 2015 で発表された、Well-Architectedフレームワークの実際の利用方法を会得するためのトレーニングです。海外では既に Well-Architected のブートキャンプが行われており好評を得ていることから、今回はじめて日本での開催に至ったということです。

以下はトレーニングの基本事項です。

対象者

・AWS のシステム設計を担当される方

・提案された AWS システム設計を評価される方

前提条件

・Architecting on AWS コース受講または同等の知識を有すること

アジェンダ

・Well-Architected フレームワークの概要

・サンプルシステムのウォークスルー

・Well-Architected の 4 つの柱（セキュリティ、信頼性、性能効率、コスト最適化）

・サンプルシステムのアーキテクチャレビュー（グループディスカッション形式）

http://www.awssummit.tokyo/bootcamp.html より。

Well-Architectedフレームワークとは

Well-Architectedフレームワークとは、文字通り AWSの優れた設計（Well-Architected） をするためのフレームワークです。フレームワークには 4つの柱（セキュリティ・信頼性・パフォーマンスと効率・コスト） があり、 一般的な設計原則 と、それぞれの柱における 設計原則 と 質問 が用意されています。

設計原則はクラウドシステムの設計におけるベストプラクティスであり、設計の指針となるものです。質問はそれに答えることでシステムをレビューすることができるようになっています。また、質問はYes/Noで答えられるようなものではなく、ビジネスの状況に応じて今すべき事や今後発生しうるリスクなどを洗い出すことができます。

これらの原則や質問を利用することで、場当たり的な対応ではなく新たな価値を追加することに集中することができ、将来のアーキテクチャに良い影響を与えることができるということです。

より詳しく知りたい方は ホワイトペーパー をご参照ください。

ブートキャンプの様子

会場はAWS Summit Tokyo 2016が行われた会場の一室で、参加者は30~40人程度、講師はAWSJのトレーナーの大村幸敬さんと、ソリューションアーキテクトの小梁川貴史さんでした。時間は全体で4時間です。

まずはじめに、昨年に行われた re:invent 2015 で Amazon の CTO Werner Vogels氏が Well-Architected を発表するシーンが上映されました。身振り手振りをしながらの熱い講演が印象的でした。その後、Well-Architectedの概要の説明があり、ディスカッションがスタートします。

ディスカッションでは、架空の会社のシステムの構成図を元に、Well-Architectedの 質問 について、 どうあるべきか（ToBe） と それを行う上での課題 をチームで検討し発表していきます。1チームが6~7名で全部で6チームあり、 質問 はチームごとにそれぞれ割り振られます。チームで検討した結果を全体で発表し、他チームや講師の方から意見をいただくという流れで、これを3回繰り返しました。

最後に講師の方からディスカッション全体の講評をしていただき、ブートキャンプは終了です。

受講したメンバーの感想

荒井（サーバーサイドエンジニア）

普段の業務では、6人以上で一つの問いかけ（ここではAWS Well-Architectedホワイトペーパーの問いかけ）に向き合う機会はあまり多くありません。あっても、「AWSアーキテクトと開発者とリーダー」など、ロールの違うメンバーで構成されることがほとんどです。そんな中、今回受講させていただいたWell-Architectedブートキャンブは、AWSに普段から携わるロールの方（AWSアーキテクトのスペシャリティを持つ方）で構成される6人のチームで、心ゆくまで議論を交わすことができる素晴らしい機会でした。

十分に議論したのち、問いかけに対する「チームとしての回答」をまとめ、その回答をAWSJのSolutions Architectの方々や他のチームにレビューしていただきます。中には、自分のチームと同じ問いかけに挑戦したチームもあり、それぞれのチームの問題に対する観点や着目点の違いにはいろいろと気付かされることがありました。

今後はこの経験を生かし、Well-Architectedホワイトペーパーの問いかけを実務に適用したいと考えています。具体的には、ITILの適用のように、項目チェックリストとしての導入から始めてみたいと思っています。

五十嵐（サーバーサイドエンジニア）

エンジニアの立場からWell-Architectedの質問を見ると、一見どう答えて良いか分からない質問もあります。ですが他の参加者の方の意見を聞いているうちに視野が広がり、システム全体やビジネス上のプライオリティといったレビューの観点が少しづつ見えてきた感覚を得ました。ディスカッションのチームには、開発をされている方や運用をされている方、経営に関わる方など、 色々なポジションの方がいた事がとても良かったです。

今後はシステムの設計やお客様に対して提案を行うときの指針として、Well-Architectedフレームワークを利用していきたいと思います。

まとめ

Well-ArchitectedはこれまでAWSのソリューションアーキテクトが培ってきたプラクティスの集大成です。クラウド上のシステムを設計・評価する上で、大変有効な評価基準になると思います。

また、「Well-Architectedの設計原則はオンプレミスに対するアンチテーゼ」と講師の方が仰っていました。これからオンプレミスからクラウドに移行する方や、オンプレミスからクラウドに移行したがクラウドを活かしきれていないという方にも大変役に立つのではないかと思います。

ぜひ、Well-Architectedフレームワークを活用してみてください。