DevOpsのテキスト研修

本番環境へのDevOpsのコードデプロイをどう低リスクにするか

多くのIT組織では、本番デプロイには手間がかかり、ストレスも伴います。平穏を保とうとして、本番デプロイの頻度をできるだけ下げがちです。その結果、一度により大きなバッチをデプロイすることになり、さらに大きな問題が起きます。こうした悪循環は悪化するばかりで、残念ながらソフトウェアやテクノロジーを主力とする企業も含め、多くの大企業がこの状態にあります。

DevOpsチームに管理とリスク軽減の仕組みを組み込む

一般的なIT組織では、開発チームがソフトウェアを作り、運用チームがデプロイします。DevOpsでは、管理とリスク軽減を担うのは、切り離された他チームではなく、必要なスキルを持ち、自力で業務を完結できる自分たちのチームです。デプロイの自動化やピアレビューもチーム内で実施します。

本番環境と本番以外の環境は、DevOpsチームが作るソフトウェアと同じくらい重要な資産です。そのため、チームは次の三つの原則を守ります。

1. オペレーティングシステム、コンポーネント、インターフェース、パッチレベル、その他すべての依存関係、そして自分たちのソフトウェアと設定について、全環境の一貫性を確保します。
2. 環境間の一貫性を損なう障害を解消することを、最優先にします。
3. すべての環境で同じ手法でデプロイします。そうすれば、本番デプロイのリハーサルが日々の業務と習慣になります。

セルフサービスのデプロイの仕組みを組み込む

自動化されたセルフサービスのデプロイは、次の手順で進みます。

1. コードを書き、トランクにチェックインする。
2. デプロイ可能なパッケージをビルドする。
3. デプロイ可能なパッケージ、依存関係、設定の準備が整っているか検証する。
4. 環境の準備が整っているか検証する。
5. 自動テストを実行する。
6. 監査とコンプライアンスのため、すべての検証結果と自動テストの結果を記録する。
7. 対象環境にパッケージをデプロイする。
8. 対象環境で自動テストを実行し、デプロイ結果を検証する。
9. 対象環境のシステム、パフォーマンス、アクティビティの指標を監視する。
10. 速やかにフィードバックを返し、問題があればデプロイを修正するかロールバックする。

デプロイとリリースは別の工程

本番以外の環境と本番環境へコードをデプロイする自動セルフサービスの仕組みがあれば、DevOpsチームは毎日システムにデプロイできます。すべてのデプロイが顧客への機能や便益の公開に当たるわけではありません。そのため、コード変更やそれに伴う追加デプロイをせずにリリースできるよう、アプリケーション、環境、またはその両方を設計します。

ブルーグリーンデプロイメントパターン

デプロイを自動化するときの課題の一つは、テストの最終段階から稼働中の本番へソフトウェアを切り替えることです。ダウンタイムを抑えるため、通常はすばやい切り替えが必要です。ブルーグリーンデプロイでは、できるだけ同一に近い二つの本番環境を用意します。常に一方が稼働しており、ここではブルーを稼働側とします。新しいリリースを準備するときは、グリーン環境で最終テストを行います。グリーンで正しく動作したら、ルーターを切り替えてすべてのリクエストをグリーンへ送り、ブルーは待機状態にします。

カナリアデプロイメントパターン
（ダークローンチとも呼ばれる）

かつて炭鉱では、早期警報の手段としてカナリアが日常的に使われていました。坑内のメタンや二酸化炭素などの有害ガスは、作業員に影響が出る前にカナリアを死なせました。鳥が苦しそうにしていれば、作業員は危険な状態だとわかりました。

炭鉱のカナリアに着想を得たカナリアデプロイは、一部のユーザーまたはサーバーにリリースを展開するパターンです。まず少数のサーバーに変更をデプロイしてテストし、その後、残りのサーバーに展開します。カナリアデプロイが失敗しても残りのサーバーには影響しないため、ダウンタイムへの影響を抑えつつ、早期警報として役立ちます。

Facebook、Googleなど多くの大手テクノロジー企業は、「ダークローンチ」と呼ばれるカナリアデプロイメントパターンを使います。全員に公開する前に、新機能を少数のユーザーに段階的に公開してテストします。ユーザーが気に入るかどうかや、システム性能への影響を確認できます。Facebookは、新機能への利用者のアクセスを管理するため、ダークローンチ用ツールを「Gatekeeper」と呼んでいます。

ダークローンチと呼ぶのは、機能の公開を通常は告知せず、まずユーザーの1%、次に5%、30%というように目立たない形で展開するからです。新機能を数日間ダークローンチした後、二度と見かけないこともあります。期待どおりに機能しなかったか、開発の方向を決めるために初期のフィードバックだけを得たかったのでしょう。

クラスター免疫システムリリースパターン

このリリースパターンはカナリアデプロイメントパターンの拡張です。性能とソフトウェアの動作を監視する仕組みを、リリースプロセスに密接に統合する必要があります。

上のカナリアデプロイの図では、オレンジ色のサーバーへの最初のデプロイが完了すると、監視システムがシステム、性能、ソフトウェアの動作に関するすべての指標を記録します。問題が一定のしきい値を超えると早期警告を発し、オレンジ色のサーバーに導入したコードを自動的にロールバックします。

オレンジ色のサーバーの自動テストと監視が良好な結果を示せば、DevOpsチームは、他の青色のサーバークラスターすべてに、より自信を持ってコードをデプロイできます。クラスター免疫システムリリースパターンは、DevOpsチームに次の利点をもたらします。

• テスト自動化で見逃される可能性がある問題に対する追加の保護策。
• 本番環境で問題が発生した際の迅速なフィードバックと自動ロールバック。

フィーチャートグル

フィーチャートグルで、アプリケーションの機能を有効または無効にできます。ある機能に必要なすべてのコードを本番システムにデプロイすれば、トグルを有効にするだけでリリースできます。通常、フィーチャートグルは実行時のシステム設定ファイルまたは設定データベースにある設定です。

フィーチャートグルがあれば、カナリアデプロイでエラーや使い勝手の問題が出たときに、DevOpsチームは機能を無効にできます。システムの拡張が難しいときに、リソース消費が大きく比較的重要性の低い機能を無効にすることもできます。全機能を稼働させた状態では拡張に課題があっても、顧客には最も重要な機能を最大限の処理能力で使ってもらえます。たとえば、ECサイトで請求書を閲覧する機能を一時的に無効にすれば、購入手続きに使えるCPUとメモリを増やせます。

サービス指向アーキテクチャでは、DevOpsチームは異なるバージョンのサービスを無効にしたままデプロイできます。新しい機能やサービスの流れに必要なすべての新バージョンをデプロイしたら、それぞれのトグルを有効にして、新しいサービスの流れを稼働させられます。

より安全なリリースのためのアーキテクチャ

規模を問わず、すべてのソフトウェア製品やサービスに当てはまる完璧なアーキテクチャはありません。

スタートアップが最初のIT基盤を構築する際は、最短、最小のコストで市場に参入し、ビジネスケースを検証するため、多くの場合、モノリシックなアーキテクチャが第一候補です。問題は、中核機能、補助機能、ユーザーやシステムのインターフェース、連携といった機能上区別できる部分が、独立したコンポーネントに分かれず互いに絡み合っていることです。Amazon、Google、Facebook、Ebayなど多くの大企業は、急速に事業を拡大し、顧客に提供する機能を低リスクでリリースし、拡張するために、途中でモノリシックなアーキテクチャを手放す必要がありました。次に進んだのは、ストラングラーアプリケーションパターンを採用した、サービス指向またはマイクロサービス指向のアーキテクチャです。

マイクロサービスへの低リスクな移行を実現するストラングラーアプリケーションパターン

複雑なシステムを完全に置き換えるのは大仕事です。多くの場合、まだ移行していない機能を旧システムで処理しながら、新システムに段階的に移す必要があります。ただし、アプリケーションの二つのバージョンを別々に稼働させると、利用側はどの機能がどこにあるかを把握する必要があります。機能やサービスを移行するたびに、新しい場所を参照するように、利用側を更新しなければなりません。

ストラングラーアプリケーションパターンでは、特定の機能を新しいアプリケーションやサービスに段階的に置き換えます。まず、バックエンドのレガシーシステムへのリクエストを受け取るファサードを作成します。ファサードは、そのリクエストをレガシーアプリケーションまたは新しいサービスに振り分けます。既存機能を段階的に新システムに移行でき、利用側は移行に気付くことなく同じインターフェースを使い続けられます。

Ebayは、ストラングラーアプリケーションパターンを使い、レガシーのモノリシックアーキテクチャをマイクロサービスへ移行した初期の組織の一つです。まず、Ebayのエコシステム内で明確に定義された共通APIの背後に、アプリケーションを配置しました。既存のコードを一度の移行ですべて書き換えずに済みました。エンジニアリング部門を、6～10人の小規模チームに再編しました。世界で最もよく使われるオークションAPIである、オークションプラットフォームの共通APIも、今では10人規模のチームで扱えます。

まとめ

ほとんどのIT部門では、将来に対応でき、拡張性が高く安全なデプロイメントパターンと、それを支えるアーキテクチャの構築は、チームの責任とされていません。しかし、チームがより速く安全にデプロイできるようにするアーキテクチャとアプリケーション機能を構築することは、DevOpsで成功するための重要な前提条件です。

チームが毎日、速く低リスクでデプロイできて初めて、継続的デプロイと円滑なリリースの恩恵を受けられます。