Yahoo! JAPANが実践するOpenStackと大規模環境でのコンテナ利用 #devsumi

2016/2/18

Yahoo! JAPANが実践するOpenStackと大規模環境でのコンテナ利用

伊藤拓矢システム統括本部サイトオペレーション本部

OpenStack 黒帯

Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

自己紹介

名前：伊藤拓矢

所属：システム統括本部サイトオペレーション本部

インフラ技術1部

担当領域

・ OpenStackをベースとしたプライベートクラウドの

設計、開発、検証、構築、運用

・アプライアンスベンダーとの調整、協力

・サーバ、OSの検証、導入など


Agenda

• データセンタを支えるOpenStack事例紹介• ハードウェアライフサイクルについて

• アプリケーションレイヤでのライフサイクル• ソフトウェアライフサイクルについて

• ライフサイクルを実現する上でのコンテナ

• まとめ


データセンタを支えるOpenStack事例紹介


OpenStackとは？

• クラウド基盤を構築するソフトウェアのひとつ

• NASAとRackSpaceからコードがOpenStackプロジェクトに寄贈され、初回のリリースは2010年でした。現在も活発に開発が進んでいます。


OpenStackとは？

様々なプロジェクトがある• インフラ基盤として動作するプロジェクト

- Cinder, Ironic, Manila, Neutron, Nova

- Barbican, Designate, Glance, Heat, Horizon, Keystone, Telemetry

• プラットホーム、ミドルウェア系プロジェクト

- Murano, Sahara, Swift, Trove

• コンテナ技術にフォーカスしたプロジェクト

- Kolla(OpenStackコントローラ側をコンテナ化)

- Magnum(COEのライフサイクル管理)

- Kuryr(Calico, Midonetなどコンテナネットワーク接続)


Yahoo! JAPANにおけるOpenStack

昨年10月27日にYahoo! JAPANは国内企業で初めてOpenStack SummitのKeynoteで発表しました



話したこと

• APIのフォーマットが変わらないことが重要

KVM

Nova

API

VM

wareCinder

API

Neutron

API

Contai

ner

Bare

metal

Apps

Platforms

Infrastructures

APIAPI

API API API API



話したこと

• 異なる環境であっても同じAPIで動作することが重要

KVM

Nova

API

VM

wareCinder

API

Neutron

API

Contai

ner

Bare

metal

Apps

Platforms

Infrastructures

APIAPI

API API API API



話したこと

• インフラのAPIはアプリに近づくことが前提

KVM

Nova

API

VM

wareCinder

API

Neutron

API

Contai

ner

Bare

metal

Apps

Platforms

Infrastructures

APIAPI

API API API API



話したこと

• Yahoo! JAPANではデータセンタ抽象化のコア技術としてOpenStackを採用した

KVMVM

ware

Bare

metal KVMVM

ware

Bare

metal



話したこと

• インフラ部門側からハードウェアライフサイクルを実施することが可能になった

KVMVM

ware

Bare

metal KVMVM

ware

Bare

metal


データセンタ抽象化の一例

オープンハードウェアの採用

• 最初にOpenStack基盤へOCPの採用後に大規模Hadoop基盤へ繋げる

• 利用者は意識しない部分での改革従来型のサーバとOpenStack上の

操作性は変らない


データセンタ抽象化の一例

オープンハードウェアの採用

• 技術向上とコスト貢献海外にて直接交渉によるスキル向上

コスト意識を持たなくてはならない


データセンタ抽象化

ハードウェア抽象化と継続的なハードウェアライフサイクルが実現


アプリケーションのライフサイクルについて

アプリケーションのレイヤまで継続的なライフサイクルを実現したい


アプリケーションのレイヤまで継続的なライフサイクルを実現したい


アプリケーションのライフサイクルについて

ハードウェア抽象化と継続的なハードウェアライフサイクルが実現

継続的なソフトウェアライフサイクルを行い、実行環境をBaremetal, VM, コンテナに対応する


アプリケーションの実行環境は人が選ばない

どこでデプロイされるかは関係ない


どこで実行されるのか

性能可搬性簡易性

△ ○ ◎オーバーヘッド大きい完全に隔離された自由な環境OS含めると軽量とは言えずBaremetalからの移行は簡単

○ ◎ ？オーバーヘッド小さい最軽量を目指すと性能対要求リソースが最適化される移行ではなく1から組み上げたい

◎ × ×性能を使い切るアプリケーションも少ない多くの場合において無駄


今日のフォーカス

コンテナ、Docker


コンテナ(Docker)の良いところ

• イメージの管理性• 上手く作れば最軽量

• 持ち運びが楽

• レイヤを重ねなくても高いメリット

• コンテナは性能劣化が少ない• エミュレーションしていないのでVMより早い

• 計算資源に対する実性能が高いため高集約


コンテナ(Docker)での注意点

VMからコンテナへの移行は難しい

1. イメージサイズが大きいとメリット薄- 可搬性が下がっていく、詰め込みすぎない



2. ネットワーク機能の違い

- 複雑なアプリケーションになるほど難しい

- コンテナ独自のNW機能も多い

- 実環境においてはCalicoなどの純粋なIPネットワークを重視



3. ストレージ機能の違い

- 永続的にデータを持たせることは考えない

- データはSwift/S3とDocker Volumeを使い分け(Object, File)


コンテナの向き不向き

• モノリシックは不向きコンテナへ重量級のデプロイはメリットが無いケースが多い

従ってコンテナするなら、軽量化、分割化を行う

• マイクロサービスもコスト高いオーバーヘッドもあり、管理対象が増えてくる

トラブルシュート大変なので、ログとメトリクスの集約が必須

メトリクスも俯瞰できないと意味無し

マイクロサービスを取り入れていない場合は、コンテナ利用の前に、軽量化と分割化に取り組む


コンテナの向き不向き

• コンテナを手でデプロイするのは大変大量にあるコンテナを組み上げていくのは人では無理

デプロイとオーケストレーションを自動でやる必要がある

• デプロイ自動化には、前段も自動化する必要があるいわゆるCIの実現

アプリケーションの作り方から変えていく

揃えるものは多い


本日のまとめ


本日のまとめ

• Yahoo! JAPANがOpenStackを導入した理由

• OCPへの取り組み

• コンテナを利用した継続的なソフトウェアライフサイクルについて


Technology

Yahoo! JAPANが実践するOpenStackと大規模環境でのコンテナ利用 #devsumi