バズワード過ぎてタイトルにするのも憚られるのですが、JavaOne2015でキーワードになったことは間違いないので...。

JavaOne2015でもDevOpsやマイクロサービスについてのセッションが多く見られました。昨年はマイクロサービスというとWebアプリケーションフレームワークからの理想論的な話が多かったですが、今年はわりと事例に基づいた話が多かったように思います。ただ事例は事例で抽象的な話にならざるを得ないわけで、目新しい話があったわけではないように思います。

あと「Java（JVM）を使っているよ」というだけのことで、直接的に「Javaでどうすべき」という話は少ないです。これもDevOpsやマイクロサービスが特定の技術の依存しているわけではないから当然のことかと思います。

事例そのものはよく知られたWebサービス系の事例が中心となっていますので、Netflix、Gilt、Twitter、Foursquareなどが色々な話をしていました。これらの事例は、まさにマイクロサービスとして数百のサービスを稼働させています。

よって、技術的なキーワードはランタイムの制御を行うことに力点が置かれていました。具体的には以下のようなものがあげられます。

• デプロイ管理：Jenkins、spinaker
• コンテナ：Docker
• コンテナ管理：Kubernetes、Marathon+Mesos、spinaker
• ルーター：Vamp、Zuul+Ribbon、ロードバランサ
• サービスレポジトリ：ZooKeeper、Eureka
• 分散ログ集約＋視覚化：Elasticsearch+Kibana、Vector

これらの技術群はサービス全体をダウンさせることなしに継続的にサービスの変更を許容するための仕掛けです。代表的な概念が「カナリアリリース」でしょう。

カナリアリリースは現状バージョンのサービスがリリースされている状態で新バージョンのサービスを並列してリリースし、段階的にアクセス先を新バージョンに切り替えていきながら、何か問題が発生したら現バージョンにアクセスを切り戻す（ロールバックする）というものです。「A/Bテスト」や「ブルー・グリーン・デプロイメント」と呼ばれる手法とも近しいものですね。

カナリアリリースの説明。新しいバージョンに5%を振ることでA/Bテストになる

カナリアは炭鉱で鳥かごにいれられて天井近くに吊るされており、有毒ガスが発生すると騒ぐため「問題の発生を先んじて発見する象徴」として使われています（カナリアにとっては迷惑な話でしょうが）。

Giltの事例では「ダークカナリアリリース」という言葉で「開発者だけがアクセスできるテストバージョンのサービスをリリースする」という話をしていました。マイクロサービス環境ではサービスをテストするのに周辺サービスをセットアップしないと稼働確認がしにくいわけですが、周辺サービスのセットアップは大変なので、そうであれば本番環境にテストバージョンのサービスをリリースしてしまい動作確認をしたほうが効率的というわけです。もちろん課金などの関わる本番に影響を与えるようなサービスについてはテスト環境を持っていると話していましたが、そうではないサービスは本番でテストしたほうが効率的なのでしょう。

Giltのセッションでの1ページ。『我々は本番環境でのテストはいけてると考えている』

また、NetflixにはChaos Monkeyという「障害をランダムに発生させるツール」があるのですが、AWSのインスタンスは毎週、アベイラビリティゾーンあるいはリージョン丸ごとは毎月障害を発生させているそうで、知ってはいたものの実際に聞いても信じられないという思いが先に来てしまいます。

Netflixのセッションで紹介された動画。左上のリージョンがダウンし、アクセスが他のリージョンに移った後、リージョンが復旧して戻っていく様子

エンタープライズ業界にいるとダークカナリアもChaos Monkeyも「それは厳しい」という話かと思います。もちろん「テスト環境よりも本番環境でテストしたほうが良い」とか「本番で障害訓練をしていたほうが本当の障害に対応できるようになる」というのが合理的であることは間違いありません。しかし、その結果として「全体的にサービス品質を高めるためには部分的な品質劣化を許容する」というのは「部分の品質を積み上げることで全体の品質を担保する」というエンタープライズ的な考え方からすると理解しがたいものです。

Netflixの考え方は「運が悪いユーザーがいることを許容することで大規模なサービスダウンを未然に防ぐ」というものですが、講演者も「Netflixがダウンすることは悲しいけど、とはいえ、絶対にダウンしてはいけないサービスではないことが前提だ」と強調していました。「軍事、医療、金融といった分野で許される考え方だとは思わない」と。

よって、DevOpsというか、マイクロサービスというか、Web企業の先端的な取り組みについては「それはそれで効率的なことは理解する」ものの「すべてのサービスがそうなるべきかは別の話」ということでしょう。

また、マイクロサービスにしても「チーム個別の自治権を許容する」ということは、チームごとに品質のばらつきがあることを許容することと同じです。これもまた従来型の品質管理からすると受け入れがたいものですね。

もちろん、エンタープライズにおいてもカナリアリリース的発想は重要でしょうし、それが認められる分野も間違いなく存在します。システム連携が複雑になる中で「単体アプリケーションレベルでの完璧な品質」など意味がないのであれば、サービス全体の品質を判断基準にしていくのは当然のことでしょう。

ただ、現状で取り組もうとすると先ほど上げたような技術群は安定的とはいいがたく維持コストは相当なものとなるはずです。とはいえ、エンタープライズでもDockerがデファクトスタンダードになりつつあるわけで、コンテナ技術を前提としたプラットフォームマネジメントツールが一般的になってくるのは間違いないものでしょう。

たとえばAzureではセキュリティアップデートのために仮想マシンの自動的な再起動が起きるため、これを前提としたアーキテクチャ（異なるロール間の受け渡しにはキューを利用する）を採用する必要がありますが、こうした割り切りは今後も増えていくはずです。

クラウドを契機に品質の概念はずいぶんを変わったものになりつつあります。例えて言うなら「ガベージコレクションがメモリ管理を不要にした」のと同じように「プラットフォーム管理ツールがインスタンス管理を不要にする」という未来が待っているのでしょう。

アジャイルとウォーターフォールと同じように「既存の考え方を安易に否定する」のはダメですが、全体的な潮流を理解しながら技術の使いどころを俯瞰していくことは重要ですね。