Apple Siriとコンテナデータ永続化プロジェクトの関係：元Siri運用マネージャーが話した

Apple Siriの運用マネジャーだったJoshua Bernstein氏は、サービスの急成長に対応すべくコンテナ化を推進した。その際の苦い経験から生まれたコンテナデータ永続化プロジェクトについて、Mesosphereの共同創立者兼CTO、Tobi Knaup氏と共に説明した。

[三木泉，＠IT]

　元Apple Siriのデータセンター運用責任者だったJoshua Bernstein(ジョシュア・バーンステイン)氏が、同サービスの運用における苦い経験を基に、現在取り組んでいることの1つはコンテナにおけるデータ永続化のためのOSS（オープンソース）プロジェクト、「REX-Ray」だ。このプロジェクトは現在、Mesos上でのDocker環境に焦点を絞って、コンテナ化アプリケーションがコンテナクラスタのどこに移動したとしても、ストレージボリュームとの接続を維持できるような、ストレージオーケストレーションの仕組みを開発している。

　Bernstein氏は2016年5月、EMC WORLD 2016で、米Mesosphereの共同創立者でCTOであるTobi Knaup（トビー・クノープ）氏とともに、これを説明した。

Siriのコンテナ移行はなぜ進められたか

Bernstein氏（右）とKnaup氏（左）

　Bernstein氏がコンテナデータ永続化プロジェクトを始めたきっかけは、Siriサービスのコンテナ環境への移行にあった。

　Siriサービスのインフラ責任者だったBernstein氏は、同サービスのためにVMware vSphere上で、「世界中で50〜60万仮想マシン」の環境を運用していた。だがある日、同氏たちは、Mesosをプラットフォームとしたコンテナ環境へ約6カ月をかけて完全に移行する計画を立て、実行した。

　「VMwareからコンテナ環境に移行すること自体が目的だったわけではない。結局のところ、私たちのVMware vSphere利用はとてもうまくいっていた。長期にわたり安定して稼働し、VMware vSphereを原因としたトラブルは全く発生しなかった。ある意味でとても心地よかった。だが、私たちは、自分たちの運用の仕方を、根本的に変える必要性を認識するようになった」（Bernstein氏）

　VMware vSphereからコンテナ環境への移行は、ある具体的な事件が大きなきっかけとなった。Siriサービスを開始してから最初のクリスマスイブに、Siriのサービスが40時間以上停止するというトラブルが起こった。原因は、現場の技術者が、誤って重要なサーバ機の電源プラグを抜いてしまったことだった。これにより、データベースが完全にダウンしてしまった。このサーバは、ネームスペースを管理しているものだった。しかもまずいことに、この際サーバの電源装置がショートし、故障した。当時Siriでは、サーバ機で26通りのハードウェア構成を持っていたが、対象となったサーバは、そのうちあまり使われない機種だった。このためスペアパーツの在庫がなく、対応が遅れた。

　Bernstein氏は担当者に、なぜこういうことが起こったのかと聞いた。答えは「手順書に従っただけです」というものだった。調査の結果、手順書に十分な更新がなされていなかったことが判明した。

　「そこで私たちは考えた。手順書を更新する必要が生まれるのはいつだろうか。何らかの作業が完了した直後だろう。ならば、『手順書の確実な更新を徹底する』のではなく、『手順書を撤廃する』べきだと考えた」

　「また、私たちは（事故の教訓から、）サーバのハードウェア構成を26から3に減らし、スペアパーツの在庫を常に確保できるようにした。しかし、電源装置が故障したら、ワークロードが別のマシンへ自動的に移動するような仕組みがほしい。コンテナはこの意味でも、従来とは全く異なる方法を提供してくれる」

　Bernstein氏はもう一つのきっかけを説明した。「Siriにおけるサービスダウンの原因の80％は、作業者のエラーか、商用ベンダーのネットワーク製品のバグだった。私はあるベンダーの製品を、全て冗長構成で導入したが、適切な切り替えが起こらないというバグも発生した。こうしたことから、私たちは今までとは全く違う何かをしなければならないことは明らかだった」

　「全く違う何か」とは、インフラの完全な抽象化だという。例えばアプリケーションを稼働したまま、インフラを完全に入れ替えるようなことのできる技術だ。また、「アプリケーションをいったん導入した後で、仮想化環境かコンテナ環境かを選択して移行できるように仕組みだ」

　そこでBernstein氏たちは、オンプレミスのデータセンターからクラウドサービスまで、多様なインフラ環境を統合し、統一的なAPIアクセスを提供できるOSSのMesosを採用、この上でDocker環境を動かす構成に移行することにした。

　「Mesos／Dockerへの移行で、インフラ環境の運用をシンプル化できた。シンプルな運用ができればスケールする。スケールすればオペレーションが効率化し、低コスト化するため、アジャイルな取り組みにつながるという良循環が生まれる」

　Bernstein氏は、『同じことをOpenStackでできないのか』とよく聞かれるという。「アップル社内では、別チームが18カ月を掛けてOpenStackを検証していた。私も検討してみたが、VMware vSphereと根本的に異なる考え方に基づく技術ではなかった」

「『12 Factor App』には矛盾がある」

　「私たちはMesos上でDocker環境を動かすという強力なコンセプトにたどり着いた。しかし、実際に移行を進めるに当たって唯一の障壁となったのが、データの永続性の問題だった」。

　他の部分は全てMesosの上で抽象化できたが、データの永続性だけはこれができなかった。Bernstein氏たちは、何とかこれを解決しようと、試行錯誤を重ねたという。「私たちは、HDFS上にソフトウェアを書いたり、オブジェクトストレージに全データを移行しようとしたり、その他、考えつくもの全てを試した」。結果的には、ボリュームマウントという、従来ながらのやり方を選択することになった。

こうした従来型のやり方では、拡張性や柔軟性に欠ける

　「だが、これでは拡張性や柔軟性に欠け、サスティナブルなやり方とはいえない。他にも、全ノードにデータをコピーする、データ管理をスケジューラーと統合するなど、新しい技術が生まれているが、複雑性などの点でどれも問題がある」

　コンテナにおけるデータ永続性の問題で困っているのはアップルだけではない。「Docker Hubで最も人気のある12のアプリケーションのうち、7つがデータ永続性に依存している」。そこでBernstein氏は、これを解決するため、REX-Rayプロジェクトを始めたのだという。

　「だいたい、新しいやり方でアプリケーションを開発する際の12の原則を提示し、バイブル的存在となっている『12 Factor App』には矛盾がある」と、Bernstein氏は指摘する。

　「12 Factor Appは、プロセスについては、アプリケーションを単一あるいは複数のステートレスなプロセスとして実行すべきだという。だが、バックエンドサービスについては、アタッチされたリソースとして扱うべきだという。バックエンドサービスを、疎結合なリソースとして扱うというのは、紙の上やWebサイトではうまくいくかもしれない、だが、私たちの仕事を楽にしてくれることはない」

「12 Factor Apps」には矛盾があるとBernstein氏はいう

MesosとDC/OSは、ビジネスのための本格的なアプリ基盤

　Mesosphere CTOのKnaup氏は、Mesosを基盤とするDC/OSについて、モダンなエンタープライズアプリのための基盤だとし、次のように説明した。

　DC/OSでは、まずオープンソースソフトウェアとして開発されているMesosが、インフラの抽象化を担っている。「マシンの障害やソフトのクラッシュへの対応、ネットワークの分割など、（論理的には）自律的に回復できるインフラを提供する」。

　次にオペレーションの品質を高めるための多様なツールを提供している。

　その上で、コンテナオーケストレーションを提供する。コンテナオーケストレーションでは、コンテナアプリを十分リソースのある物理マシンに再配置する。これはリソースの利用効率を高めるとともに、拡張性と柔軟性を実現するという点で不可欠だ。DC/OSでは、リソースの抽象化の上でこの機能を提供することにより、コンテナ運用環境としての価値を高めている。

　「だが、今日あるマシン上にデプロイされたコンテナアプリは、明日には別のマシン上に移る可能性があることは確かだ。特にネットワークやストレージが、これに十分対応し、拡張性が確保されるようにしていかなければならない。また、オンプレミスのデータセンターからパブリッククラウドまで、均一な環境が提供されることで、柔軟にこれら多様な環境を使い分けられるようにならなければならない」

　「コンテナおよびDC/OSの優れた点は、開発者に大きなパワーを与えることにある。開発者はDC/OSに対し、自らがデプロイするアプリケーションについて、どのように運用したいのかを記述することで、あとは全てをDC/OSが担ってくれる。サポートチケットを発行するなど、人的エラーの原因を作ることもしなくて済む。こうしたパワーを、ストレージの世界でも実現できることが重要だ。アプリケーションに必要なストレージ容量、必要なパフォーマンス、バックアップなどのデータサービスを指定しさえすれば、自動的に実行されなければならない」

　「REX-RayをDC/OSに実装した理由は、開発者自身が、ストレージについてもコントロールできるようにすることだ。自分のアプリケーションがどこに移動しても、ストレージサービスが適用されるようにして、ストレージ周りの作業をとても簡単なものにしたい。これを支える技術として、REX-Rayがサポートする全てのストレージに対応し、これらを同一のAPIで提供できる」

　Knaup氏は、今後もBernstein氏らと協力し、データ永続性機能の適用範囲を拡大していくことで、「コンテナベースのモダンなエンタープライズアプリの運用支援」というDC/OSの価値を、さらに高めていきたいと話している。