OpenStack批評」2015

OpenStack批評」2015

1. 1. 1 OpenStack批評2015 2015/12 日商OpenStackセミナ発表資料 GMOインターネット株式会社 オープンネットワーキングチーム 中里 昌弘 masahiro-nakazato@gmo.jp
2. 2. 2 今回の発表の内容 OpenStackを利用した比較的大規模なパブリッククラウドサービス を企画から運用している体験からの感想談＆考察です ネットワークエンジニア＆中間管理職の視点となっています 1. 紹介情報 2. 感想 3. 考察 の三部構成です 導入の意思決定の参考になれば幸いです・・・
3. 3. 3 1. 紹 介 情 報 自己紹介 GMOインターネットのOpenStack活用例 2015年のOpenStackへの関わり
4. 4. 4 自己紹介 ネットワークエンジニア/マネージャとして バックボーン/クラウドネットワーク/その他の設計運用に従事していた 2014/8頃より新しいクラウドサービスの開発に本格的に携わる サーバ構築運用は前職から経験あり プログラミングは独学で業務改善用ツールを作るなど OpenStackは好きでもなく、かといって嫌いでもなく
5. 5. 5 GMOインターネットのOpenStack活用例 ソーシャルゲーム向け クラウドサービス 「アプリクラウド」 自由度の高い クラウド・VPSサービス   「ConoHa」 パブリッククラウドサービスの基盤としてOpenStackを活用 havana & juno使用 grizzly & juno使用
6. 6. 6 2015年のOpenStackへの関わり 日本、アメリカ、シンガポールでサービス展開する新しいクラウド基盤 のネットワーク関連のプロジェクトマネージャとして以下タスクを担当 ・各リージョンのクラウド基盤の物理ネットワーク設計・構築・調達 （従来のネットワークエンジニアの仕事） ・OpenStack junoを利用したクラウド基盤のサービス設計・開発 （主にneutron周り） ・全てオープンソース、自社開発でサービス作成を行いました ＃まあ色々しんどかったです
7. 7. 7 2. 感 想 OpenStack 何がおいしいですか？ OpenStack 何が大変？ 何が大変でしたか？自分の場合 neutron関連の独自の実装 byGMO どんな改修だったのかというと どうやって乗り越えたというと 参考:サービス開発の体制モデル 感想からの教訓
8. 8. 8 OpenStack 何がおいしいですか？ ・クラウドサービスやVPSサービスのベースを無料で構築出来る ・クラウドリソース（コンピュート、ネットワーク、ストレージ）を  APIで一括操作管理  ・gre,vxlanでのオーバレイ接続やアドレッシング、ロードバランサ等  のサービスをソフトウェア上で実現 ・ネットワーク機器も操作出来る ・バグは自分でなおしたり、仕様はカスタマイズも出来る ・進化・機能改善が早い
9. 9. 9 OpenStack 何が大変？ ・管理者が楽になるものではなく、改良を加えて  クラウドサービスを作るベースとなる玄人向けの荒削りなキット ・複雑で理解して稼動までに時間が掛かる ・重く小規模な環境で使うメリットは感じづらい ・開発と運用に継続的に人的リソースを割かれる ・バグが多く大規模環境ではスケールの問題が多い
10. 10. 10 何が大変でしたか？自分の場合 ・OpenStackの仕様を理解して動かすまでに時間を持っていかれる  サーバ＆プログラマ向けのツールでありネットワークの人からすると  全くの異文化 ・サービスとしてリリースする都合、販売側で作って欲しいものは  決まっていて、仕様の十分な理解や検証が不足している状態で  サービス仕様を決める必要があった ・多数のバグフィックスとサービス仕様に合わせたカスタマイズをする  必要があった
11. 11. 11 neutron関連 独自の実装例 byGMO ・spoofing guard ・port create speedup ・iptables speedup ・QoS &filtering ・LBaaS service ・IPv6 addressing ・vm default traffic filter ・validation hacking ・…..etc ＞皆からは辛かったの声 ホントお疲れ様でした
12. 12. 12 どんな改修だったのかというと ・独自のサービスを安価で提供する為 ・そもそもちゃんと動かない機能の実装 ・スケール問題への対応（OpenStackを大規模環境で動かす工夫） ・パブリッククラウド向けへの仕様変更 （セキュリティやabuse運用向け） ＝＞これってガラパゴス仕様？ 
13. 13. 13 どうやって乗り越えたというと ・結局はコードの修正や独自実装で対応することとなり、  玄人のプログラマ&サーバエンジニアの工数を相当割いた ・周囲の理解   ＞オープンソースを利用した開発はつまづきながらやっていく ・junoを採用していたがkiloのコードを一部バックポート等  ＝＞結局は人と時間を投入すればなんとかなる・・・・    クラウドは総力戦！
14. 14. 14 参考:サービス開発の体制モデル OpenStackを利用したサービス開発には以下の要素を持った組織に 分かれて担当を行う #パブリッククラウドだとa. の項目で相当な工数が発生する a.ユーザインターフェース    ：画面、API a.制御ロジック ：wrapper, etc… a.OpenStack ：neutron,nova,keystone b.ミドルウェア   ：openvswitch,iptables….. b.物理インフラ ：network機器,サーバ
15. 15. 15 感想からの教訓 ・仕様の理解と検証を十分に行ってから利用する   ＞バグや仕様上の落とし穴が本当に多い ・OpenStackを利用したサービス仕様決定者は自分達にする   ＞プライベートクラウドならそれが可能・・？ ・プライベートクラウドにとどめる&使い方を限定する   ＞OpenStackの管理はVMの管理に限定する等 ・junoでぶつかった問題の多くはlibertyでは改修されていた   ＞なんだかんだで進化しているOpenStack
16. 16. 16 3. 考 察  ポジションによるメリット クラウドの勝手な定義 ネットワーク機器のOpenStack対応について ベンダロックインの考え OpenStackから扱うネットワークリソース 参考：経験からの推奨構成 2015/12現在 ここで耐用年数の話 システムの耐用年数 組織に於ける人の耐用年数 OpenStackを触るエンジニア 考察の総括
17. 17. 17 ポジションによるメリット 立ち位置によりOpenStackを選択する・携わるメリットは異なる ・意思決定者   コスト (やはりこれに尽きると思う) ・中間管理職   管理工数を減らしたい   サービス開発を効率よく行いたい ・エンジニア   スキルアップしたい   複雑な仕組みを触ってみたい   夢がある＆OpenStackがあれば問題は解決できる
18. 18. 18 クラウドの勝手な定義 ・決められたルールに従って準備したリソース（サーバやネットワーク機器）  をプログラムが扱えるリソースにしてサービス利用者に提供する ・ネットワーク関連リソースはプログラムが扱えるモノとする文化が  サーバやストレージに比べ遅れている  配線と機器を繋いで色々な通信経路を作る特性上しょうがない ・クラウド向けシステム構成だとネットワークリソースも決められた  ルールに基づいて準備するのでプログラムから比較的扱いやすい  （それをかっこよくSDNとか言ったりする） ・コストを抑えてスピード感あるサービスを提供する為の仕組み
19. 19. 19 ネットワーク機器のOpenStack対応について ・各メーカさんからOpenStackの操作に連動してネットワーク機器  を操作するpluginが出ている ・ただ、以下の組み合わせが対応状況となる為に  利用可能な状況の把握が必須である  ①ネットワーク機器とOS ②利用できる機能 ③OpenStack Version ・弊社の場合、メーカ製pluginでは  利用できる機能が足らずに全て独自のものを作成・・・  ＝＞それなりの工数発生＆属人化問題を抱える
20. 20. 20 ベンダロックインの考え ・プライベートクラウドにOpenStackを活用している企業の事例を  聞くとOpenStackの仕様や搭載している機能に沿ったサービス仕様  としておりうまい！と思った でもある意味ロックイン ・クラウドはリソースをルールに従って準備するという特性上、  機器はベンダpluginを使わなくても結果として えることになり、  結果としてロックインしている ＝＞なら使ってしまえという考え   時間や工数は有限なので、いかに効率良く導入するか
21. 21. 21 OpenStackから扱うネットワークリソース 今のところ下記リソースを扱えます ・レイヤ２接続 ・ルータ（floating IPの概念等で若干特殊） ・ロードバランサ ・パケットフィルタリング ・VPN ・IPv4&IPv6 アドレッシング この中で安定して使えるのはレイヤ2接続くらい 他はスケール時の問題や安定性に難あり
22. 22. 22 参考：経験からの推奨構成 2015/12現在 比較的大規模まで対応＆安定したVMリソースへのアクセス、 という要件をオープンソースだけで満たす＆大きな改修を入れない 場合は以下構成で組むとよいと思います ・VM External接続（グローバルIP等）はVLAN＆レイヤ2で直接VMに  割り当てる つまりfloatingIP構成は取らない ・network driverはopenvswitch とlinuxbridgeはお好みで ・VM localnetwork接続はVLAN or VXLANはお好みで  ・IPv6アドレッシングは使わない ・セキュリティグループは頻繁に操作しないのであれば有効でも
23. 23. 23 ここで耐用年数の話 話題は変わりますが、 ・システムの耐用年数 ・携わるエンジニアの耐用年数 ・OpenStackを触るエンジニア という内容について触れてみる
24. 24. 24 システムの耐用年数 ・CPU、メモリ、ストレージ、帯域の性能向上は激しく、  特にサーバはパブリッククラウドだと３年で売れなくなる ・ネットワーク機器は比較的長持ち 1VMで10Gも出されたらね。。 ・中のOSやソフトウェアのバージョンが古くなるとセキュリティ問題  やツールへの未対応になってしまう ・それらを踏まえると雑ですが押し並べて５年程でクラウドシステムは  寿命を迎えなるのではないでしょうか
25. 25. 25 組織に於ける人の耐用年数 ・転職、昇進、部署移動、、、組織で同じポジションに居続けられる  人間は少ないのではないだろうか ・社内や社外の人をみていると５年くらいでやることは変わっている  人が多い ・作成したシステムを運用する人間を維持し続けられるのかという課題 ・システムはリリース後の運用や改修がとても大事..
26. 26. 26 OpenStackを触るエンジニア ・オープンソースを使いこなすGEEKなエンジニアは数少ないし、  補佐する体制づくりはそれなりに大変 ・スキルあるエンジニアを止めておくには維持費がかかる ・ベンダロックインよりも怖い属人化   複雑な仕組みには属人化が付きもの    ex)この人がいなくなったらシステム維持が出来ない等 ・ノウハウは伝えきれない、受け取れきれない
27. 27. 27 考察の総括 ・OpenStackを採用するモチベーションはやはりコスト ・オープンソースならではの問題があるので、  各組織の文化や力量に合わせた付き合い方をするとよい ・クラウドも耐用年数があり、それを見据えた人やモノを える ・ノウハウはお金を払って買うという考えもあり  メーカさん、ベンダさんに期待してみたり・・・  OpenStackは触ったことない人には何がなんだかサッパリだと思います  特にネットワーク周りは鬼門なので