ヤフーのデータセンターを支える基盤としてOpenStackを採用
セッション後半では、伊藤氏が「Yahoo! JAPANが実践するOpenStackと大規模環境でのコンテナ利用」と題して語った。
OpenStackは、クラウド基盤を構築するソフトウェアの一つだ。NASAとRackSpaceからコードがOpenStackプロジェクトに寄贈され、初回のリリースは2010年。現在も活発に開発が進んでいる。
ひとくちにOpenStackと言っても、インフラ基盤やミドルウェアなどを対象にした様々なプロジェクトがあるが、その中からヤフーは、10個ほどのプロジェクトを利用している。
2015年10月、OpenStack Summitが東京で開催された際には、ヤフーは国内企業として初めてキーノートで発表したという。発表した内容は以下の5つ。
- APIのフォーマットが変わらないことが重要：APIがハードウェアの違いを吸収し、抽象化する。
- 異なる環境であっても同じAPIで動作することが重要：異なるランタイム環境KVM、VM、ベアメタルであっても、同じコンサルティングリソースを提供する目的においては、同じAPIで動作することが求められている。
- インフラのAPIはアプリに近づくことが前提：プラットフォームから見てAPIをインフラよりもアプリ側に近づけることで、より柔軟にアプリケーションを作ることができる。APIのレイヤーで違いを吸収、抽象化する。
- ヤフーはデータセンター抽象化のコア技術としてOpenStackを採用：OpenStackにより、データセンターの抽象化をし、常に新しいハードウェアの導入することが可能になった。
- インフラ部門側からハードウェアライフサイクルを実施することが可能になった：従来インフラ部門は、受け身で動くことが多かったのだが、能動的に新しいものにどんどん替えていくことができるようになった。
ここで伊藤氏は、データセンター抽象化の一例として、オープンハードウェアの採用について話した。OpenStackはインフラ部門側が主導して導入しており、データセンターにおける新たなチャレンジにも使われている。
まず、OpenStack基盤としてOCP（Open Compute Project）を採用した。抽象化することで、ハードウェアプラットフォームの変更を行うのだが、リスクが高いチャレンジにも関わらず問題なく進めることができた。結果、継続的なハードウェアライフサイクルが実現している。物理的な経年劣化があるし、電力対性能という面で見ても古いものは入れ替えていく。この際、海外においてベンダーと直接交渉したことによりスキルが向上し、コスト削減も実現している。
継続的なソフトウェアライフサイクルのために有用なコンテナと、コンテナ利用の注意点
伊藤氏たちは、アプリケーションのレイヤーまで継続的なライフサイクルを実現したいと考えている。ハードウェアだけでは得られるメリットが限られるからだ。ランタイムなどで新しい技術が生まれてきているので、それに併せてソフトウェアの動作環境も変えていきたい。
継続的なソフトウェアライフサイクルを行うためにはまず、実行環境への依存を無くす必要がある。ものによっては環境を選ぶ必要があるが、ほとんどのものは、依存を無くすことができる。加えて実行環境をベアメタル、VM、コンテナに対応する。
望ましいのは、アプリケーションの実行環境をシステムが自動的に提供し、人が選ばないようにすることだ。「リソースの使用が効率化されるので、メリットが大きい」と伊藤氏。
ここで、伊藤氏は下記のスライドを見せながら、KVM、Docker、ベアメタルを比較して見せた。
アプリケーションのレイヤーまで継続的なライフサイクル実現に寄与する期待されるのが、伊藤氏のセッションのもう一つのテーマである、コンテナ（Docker）だ。
コンテナの利点として伊藤氏は次の2点を挙げた。まずは「イメージの管理性」。上手く作れば最軽量で、持ち運びが楽で、デプロイの高速化に効果を発揮する。レイヤーを重ねなくても高いメリットがある。
さらに「性能劣化が少ない」ということ。エミュレーションしていないのでVMより早く、計算資源に対する実性能が高いため高集約であることも利点だ。
一方、コンテナの注意点についても述べられた。まず「VMからコンテナへの移行は難しい」ということ。なぜならイメージサイズが大きいと、メリットが薄いからだ。可搬性が下がっていくし、詰め込みすぎないのがポイントだ。
次に「ネットワーク機能の違い」があるということ。複雑なアプリケーションになるほど難しく、コンテナ独自のネットワーク機能も多い。実環境においてはCalicoなどの純粋なIPネットワークを重視するのだという。
最後の注意点として「ストレージ機能の違い」もあるという。コンテナに永続的にデータを持たせることは考えるべきではなく、最近ではDockerボリュームに対応したストレージアプライアンスが出ている、という。データはSwift／S3とDocker Volumeを使い分けることにより、コンテナでも安心してデータを預けることができるのだそうだ。
何でもコンテナにすればいいかと言えばそうでもない、コンテナにも向き不向きがある。まず、モノシックなアーキテクチャーには不向きである。コンテナへの重量級のデプロイはメリットが無いケースが多い。従って、コンテナにするなら、軽量化・分割化を行う必要がある。
一方、マイクロサービスもコストが高い、という。オーバーヘッドもあり、管理対象が増えてくる。トラブルシュートが大変なので、ログと、メトリクスの集約が必須だ。メトリクスも俯瞰できないと意味が無いのだそうだ。
また、コンテナを手でデプロイするのは大変、と伊藤氏。大量にあるコンテナを手でデプロイするのは、事実上不可能だ。そのため、デプロイとオーケストレーションを自動でやる必要があるのだそうだ。
そしてデプロイ自動化をするなら、前段も含めて自動化する必要がある、という。いわゆるCIの実現だ。アプリケーションの作り方から変えていかなければならず、コンテナ導入の前には揃えるものが多いのだという。
最後に伊藤氏は「コンテナは、継続的ライフサイクルの実現に適している。コンテナ活用の手助けをしていきたい」と語り、セッションを締めくくった。
お問い合わせ
ヤフー株式会社
