BT

Adrian Cockcroft氏の論じるカオスアーキテクチャ - “4つのレイヤ、2つのチーム、ひとつの考え方”

| 作者: Daniel Bryant フォローする 631 人のフォロワー , 翻訳者 h_yoshida フォローする 1 人のフォロワー 投稿日 2018年1月17日. 推定読書時間: 5 分 |

原文(投稿日:2017/11/17)へのリンク

先日のQCon San Franciscoでは、Adrian Cockcroft氏が“Chaos Architecture”について講演し、クラウドネイティブアーキテクチャの進化と、より安全で安全なシステムを生み出す上でカオスエンジニアリングがどのように適用可能かを論じた。その中で氏は、効果的なカオスアーキテクチャとエンジニアリングは“4つのレイヤ、2つのチーム、ひとつの考え方”で構成されると説明した。すなわち、インフラストラクチャ・スイッチング・アプリケーション・人々の4層、カオスエンジニアリングとセキュリティレッドの2チーム、そして“改善するために破る(break it to make it better)”という考え方だ。

AWSのクラウドアーキテクチャ戦略担当副社長であるCockcroft氏の講演は、モノリシックアプリケーションの作成から始まって、マイクロサービス、最終的には機能(“サーバーレス”)に至る、ソフトウェアアーキテクチャの進化を示すことから始まった。モノリシックなコードベースを分割する最初の試み -- 古典的なサービス指向アーキテクチャ(SOA) -- は、SOAP経由のXMLのような高頻度かつ大容量の通信を行なう、粒度の粗いミニ・モノリスを結果として生み出すことになった。その後のマイクロサービスアーキテクチャスタイルの登場により、多くはRESTなどのインターフェースを経由して、一般的にはHTTP上で簡潔なJSONやバイナリエンコードされたペイロードを、より高い頻度で通信するようになった。

Microservices to functions

5年前のマイクロサービスは標準的なビルディングブロック -- 多くはDBaaSやMSaaS、NoSQL DBサービスなど、クラウドプロバイダの提供するサービスやプラットフォームユーティリティ -- を使って構築され、サービス自体はビジネスロジックをカプセル化したブロックを組み立てるグルーであった。その後のAWS LambdaなどFaaS(Function-as-a-Service)サーバレスの登場により、 3年前、ビジネスロジックのグルーであるコンポーネントは短命(ephemeral)な機能へと発展した。このアプローチは、システムアーキテクチャの設計方法を根本的に変えた – システムがアイドルであればシャットダウンし、顧客に課金されることはなくなった。

このアーキテクチャ変更に伴うアプリケーション設計のベストプラクティスの同時進化は、主に“クラウドネイティブ”と呼ばれる。ここでCockcroft氏は、アーキテクチャのための一連のクラウドネイティブの原則を紹介した – 事前支出CAPEXに代わる重量課金PEX、API経由のセルフサービス的利用と自動プロビジョニング、既定としてのグローバル分散、クロスゾーンおよび地理領域的な可用性モデル、高利用率 – 40%以下であればスケールダウン、堅牢な継続的デリバリパイプライン経由の不変コード展開、などだ。

Cockcroft氏はプレゼンテーションの途中でギアを替え、カオスエンジニアリングとカオスアーキテクチャに話題を移した。氏が考えるその本質は、“4つのレイヤ、2つのチーム、ひとつの考え方”という言葉で表される。最初の2つはインフラストラクチャとスイッチングだ。顧客のリクエストは一定のローカルリージョンやサービスにルートされなければならない。データはレプリケートされなければならない。障害時のリクエストはアクティブなサービスに再ルーティングされなければならない。スイッチングのメカニズムはスイッチされる冗長コンポーネント以上の信頼性を持たなければならない。

次のレイヤであるアプリケーションは、あらゆる障害の“爆発半径”を制限するようなマイクロサービス設計によって、よりレジリエントにすることが可能である。サーキットブレーカはダメージを限定化し、隔壁(bulkhead)はその拡散を防止する。Staring Bank -- 英国の先進的な銀行 -- のGreg Hawkings氏のDITTO(Do Idempotent Things To Others)アーキテクチャを引合に出しながら、Cockcroft氏は、更新と削除のセマンティクスの回避と組み合わせることにより、レジリエントなシステムをより簡単に実現できる、と説明した。

第4のレイヤである人々(people)は、レジリエントなシステムを構築するための中心的なコンポーネントである – 予期しないアプリケーションの振る舞いは、しばしば人による介入を招き、結果的に状況を悪化させる。実際の火災では、避難訓練(Fire drill)による対応方法の訓練が人命を救う -- しかしITでは、誰が“避難訓練”をするのだろう?氏が提案した“2チーム”は、カオスエンジニアリングチームとセキュリティレッド(security red)チームだ。

Chaos Architecture

カオスエンジニアリングチームは、NetflixのSimian ArmyFailure Injection TestingChAPGremlinといったツールを活用した訓練(Game Days)を実施して、人々に対して障害への対処方法の訓練を行なう。セキュリティレッドチームはSafestack AVAMetasploitAttackIQSafeBreachなどのツールを駆使して、積極的なシステム侵入を試みたり、コントロールされた環境下でエンジニアに不適切な(安全でない)行動を行なわせたりする。どちらのチームでも中心となるのは、“改善するために破る”という考え方だ。

講演の最後にCockcroft氏は、リスク許容度について議論し、組織にとってより重要なことは何かを問うた。可用性 – 許容的かつ“障害時に安全(failing open)”であること、あるいは一貫性とセキュリティ、それらに関連するダウンタイム。“改善するために破る”というマントラは、実際には“安全にするために破る(break it to make it safer)”ことでもある。このアプローチに関するリソースとしては、他にTodd Conklin氏の“Pre Accident Investigation Podcast”、John Allspaw氏の“stella.report”、Sydney Dekker氏の“Drift into Failure”などが挙げられる。障害はシステムの問題 -- 安全マージンの欠如 -- であって、(ひとりの)人為的ミスを問題の原因とするような概念は正しくない。

Adrian Cockcroftの講演“Chaos Architecture”のスライド資料(PDF、8MB)は、QCon SF Webサイトで確認できる。講演を収めたビデオは、今後数ヶ月中にInfoQで公開される予定だ。

 
 

この記事を評価

採用ステージ
スタイル
 
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT