クラウドネイティブな運用を実現する

運用の成熟を推し進めるためには、マイクロサービスアーキテクチャや継続的デリバリ、DevOps文化、プラットフォーム自動化が必要だ、とCasey West氏はいう。この4つは組織全体を変革し、継続的に顧客へ価値を提供するクラウドネイティブな運用を実現するのを助けてくれる。

PivotalのプリンシパルテクノロジストであるCasey West氏はAgile and Software Architecture Symposium 2016で講演し、運用の成熟への旅について語った。InfoQはこのカンファレンスをインタビューや記事で取り上げている。

マイクロサービスは計算リソースの最適化ではない、と氏は言う。アーキテクチャと組織を支援するのが目的なのだ。マイクロサービスを導入することで一枚岩の配置戦略の遅さとリスクを回避し、組織の文化と配置戦略の効率の悪さを明らかにする。

DevOpsは協力して働くことを改善する、と氏は言う。DevOpsは協力し、学習し、共有する文化を作るのに使えるのだ。

氏の考えでは、チームの最初のスプリントではビルドパイプラインの構築と自動化を実施するべきだ。プラットフォーム自動化の特徴は実用最小限のプラットフォームを構築するのに利用できる。

• ダイナミックDNS、ルーティング、ロードバランシング
• サービスブローカーの支援
• インフラのオーケストレーション
• ヘルスマネジメント、監視、リカバリ
• 不変のアーティファクトリポジトリ
• ログ収集

InfoQはこのカンファレンス後、Casey氏にインタビューし、クラウドネイティブな運用を達成し、継続的デリバリのプロセスとDevOpsの文化を確立するために必要なことや、組織がクラウドネイティブなソフトウェアを開発しデリバリしているかどうかを評価する方法について話を聞いた。

InfoQ: クラウドネイティブな運用とはどんなものでしょうか。

Casey West: クラウドネイティブな運用とはクラウドの利点を生かした大規模シスエム向けのソフトウェア設計とデリバリのための全体的なアプローチです。"DevOps"やマイクロサービスのような配置や運用のスループットを最適化するモダンなアプローチに注力するというより、講演を聞きに来た方にビジネス価値のデリバリを成熟させるための4つの鍵となるコンポーネントについて考えてほしいと思っています。

InfoQ: あなたの話では、マイクロサービスアーキテクチャ、継続的デリバリプロセス、DevOps文化、プラットフォーム自動化の4つが必要だと話していましt。なぜこの4つが必要なのでしょうか。

West: この4つが必要なのはそれぞれが依存しあっているからです。例えば、継続的デリバリによってプロダクションへの経路を自動化していない状態で、開発チームがマイクロサービスアーキテクチャに向かってしまったら、タイムリーかつ低コストでプロダクション環境を更新するのがとても難しくなります。マイクロサービス戦略の成功は、効率的な配置プロセスに依存しているのと、同様、DevOpsの性質である共有された責任や協力体制の文化にも依存しています。

同様に、成熟した、完全に自動化されていて回復力のあるプロダクション環境も必要です。もしプロダクションがアプリケーションにとって最悪の環境で、定期的に手動の介入が必要であれば、スループットを増やしリスクを小さくするという大きな目的は達成できないでしょう。

InfoQ: 継続的デリバリのプロセスを確立したい組織は何をすればよいでしょうか。

West: 継続的デリバリは複数のチームの協力と協調が必要になります。開発者とテスターは信頼性のある自動化テストを一式を作る必要があります。ソフトウェアに対する変更がされた場合、テストを通過したなら、それはチームにとってこの変更がシステムを壊さないという高いレベルの確証になります。

自動デリバリパイプラインはテストの品質から始まり、最終的にはボタンクリックによるプロダクションへの配置というひとつのステップになります。完全な自動配置戦略は大変重要であり、開発者、リリースエンジニア、IT、運用、の間で協力する必要があります。多くの環境では、ダウンタイムなしでの自動配置("ゼロダウンタイム配置"や"ブルーグリーン配置"と呼ばれる)はキャパシティと物理リソースの確保が自動化されており、配置時のへん呼応が小さい場合に可能になります。

配置のときのこれらの小さな変更は、配置の最後の鍵であり、プロダクトやプロジェクトマネジメントのようなビジネスへの関心と協調する必要があります。仮に組織がプロダクションの更新を年に2回、3回しかしないのなら、配置のサイズは巨大になります。2週間に1度のリリースですら、数千行のコードの変更と異なるシステムの変更を一緒にやることになる場合もあります。この場合、システムを変更するのは高リスクになります。もし、プロダクションで誤動作が起きたら、どの変更が問題を引き起こしたのかどのように知ればよいでしょうか。トリアージの方法、効率的に修正の方法はどうでしょうか。

小さな変更にすることでリスクが小さくなります。一度に少しずつ変更し、順番にプロダクションに配置します。変更は、たった1行かもしれせんし、数十行かもしれません。この規模の変更なら推測がつきます。システムに対する影響もよりはっきりと理解できます。誤動作したらどの変更が引き起こしたのかわかりますし、より素早く反応できます。

この戦略を導入する場合、プロダクションの変更や配置は機能のリリースと分離する必要があります。継続的デリバリではこのふたつは同じではありません。ビジネス上、このことを理解しておく必要があります。開発では機能フラグやA/Bテストをこのアプローチで計画しなければなりません。従って、機能リリースはコードの配置とは独立して管理する必要があります。

InfoQ: DevOpsの文化はどのような構成要素で出来上がっていますか。

West: 私の意見では、ソフトウェアデリバリチームの効率さに対してDevOpsの動きの最も重要な貢献は、文化です。"CALMS"という頭字語によく表現されています。つまり、協力(collaboration)、自動化(automation)、学習(learning)、計測(measuring)、共有(sharing)です。これらは特別なアクションではなく、働き方です。効率的なチームの特徴であり、現在の組織で耕されているものです。

InfoQ: クラウドネイティブなソフトウェアを開発できる組織かどうかはどのように評価しますか。

West: 今の自分たちのアーキテクチャやプロセス、文化、自動化を繰り返している組織は途上にあると言えます。そのような組織はこの4つのビジネス価値のデリバリに同時に取り組む必要があります。クラウドの利点を享受することに成功するチャンスをつかむためです。成熟したマイクロサービスアーキテクチャと信頼できる継続的デリバリプロセス、応答性の高いDevOps文化、そして、完全に自動化されたプラットフォームを持つ組織はクラウドネイティブなソフトウェアの開発とデリバリで大きな成功を納めています。

InfoQ: クラウドネイティブな運用を実現したい組織にたいしてアドバイスをお願いします。

West: Fred Brooksのエッセイ"No Silver Bullet"のアドバイスを心に留めておきましょう。

"技術にしろ、マネジメント手法にしろ、それ自体で10年に渡って生産性、信頼性、単純さの領域において、数倍の改善を約束するようなものはない。"

私はこれは未だに真実だと思います。しかし、最近のクラウドベースのプラットフォームや組織の文化、自動化されたデリバリ、ソフトウェアの設計のおかげで、これらを結集して、生産性や信頼性、シンプルさを促進することができます。大規模なクラウドネイティブのソリューションをデリバリするとき、この4つの利点を生かしてリスクを小さくし、スループットを増大し、競争的であり続けるという方法以外はないと思います。