Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

コンテナは次世代サービスの主流になるか?

2,399 views

Published on

TECH x GAME COLLEGE #3 プレゼンテーション資料

Published in: Engineering
  • Login to see the comments

コンテナは次世代サービスの主流になるか?

  1. 1. コンテナは 次世代サービス開発の 主流になるか? TECH×GAME COLLEGE プレゼンテーション資料 2018/9/12 さくらインターネット株式会社 さくらインターネット研究所 鷲北 賢 (C) Copyright 1996-2018 SAKURA Internet Inc
  2. 2. 自己紹介 • 鷲北 賢(わしきた けん) • 1998年4月入社 • バックボーンのお守りからサービス開発まで ─ 初期の専用サーバ、データセンター構築 ─ オンラインゲームプロジェクト ─ CTO兼取締役、などなど • 2009年より、さくらインターネット研究所 所長 ─ 仮想化技術の研究(Linux KVM) ─ さくらのVPS開発ヘルプ • 2011年~2017年、さくらのクラウドPD兼務 • @ken_washikita • https://facebook.com/ken_washikita 2
  3. 3. さくらインターネット株式会社 3
  4. 4. オンラインゲーム事業をやっていました • Dungeons & Dragons Online STORMREACH • 創業当初からゲーム事業をホスティングするのが夢 • アメリカのオンラインゲームを買付けてサービス展開 • いろいろあって撤退 4
  5. 5. さくらのコンテナ技術への取り組み • シルバーメンバーです • エヴァンジェリストチームを中心に業界動向の把握と 広報に努めています https://www.slideshare.net/zembutsu/container-and-cloud-native-overview- distribution 5
  6. 6. もくじ 1. 自己紹介 2. CLOUD NATIVE -現状のおさらい- 3. 事例1:Mastodon 4. 事例2:NETFLIX 5. サービス開発におけるコンテナの意味 6
  7. 7. CLOUD NATIVE 現状の おさらい 7
  8. 8. 時はまさにクラウドの時代 • 仮想サーバの出現でインフラの様相が大きく変わった ─ クリックで即座に作成/削除できるサーバの登場によって 使われ方が大きく変化した • サーバのライフサイクルが短くなった ─ オンプレミス:3年~7年 ─ クラウド初期:1年~3年 ─ 現在:1ヶ月未満も普通になってきた FaaSの登場で秒単位のケースも有り得る状況に • スケールアウトの発想 ─ 高負荷に対して、性能強化(スケールアップ)ではなく、 多数のサーバに分散することで対応すること ─ アプリケーションの設計も変化 8
  9. 9. Immutable Infrastructure • 直訳すると「不変」だが「使い捨て」の方が分かりや すい • オンプレ時代なら「アップデート」していたサーバを、 そっくり捨てて新規に作り直すという発想 ─ クラウドサーバならば比較的容易に可能 ─ ライブラリのアップデートすら「サーバごと作り直す」 • なぜそんなことをやるのか? ─ 冪等性はすばらしい(インフラをコード化できる) ─ しかし冪等性の維持は非常に困難 ─ 追加やアップデートに苦心するより、新規に作り直すコス ト(再作成の時間)を減らす方が楽であるという判断 ─ 障害時のリカバリも楽になる 9
  10. 10. Scale-out, not UP 10 https://www.slideshare.net/randybias/architectures-for-open-and-scalable-clouds Randy Bias, 2012 スケールアップ: サーバはペット 病気になったら看病する スケールアウト: サーバは家畜 病気になったら撃ち殺す
  11. 11. Infrastructure as Code • インフラをコードで記述する ─ コードを実行するとインフラが構築される ─ 元々はオンプレやVMにおいて発展してきた ➢ ChefやAnsible、Terraformなどに結実した ─ クラウドVMで、ある程度実用になった ─ サーバだけでなくネットワークも記述できるようになった • ChefやAnsibleの提供する冪等性には限界がある ─ ドライバを含むカーネルから、アプリケーションを実行す る言語パッケージまでのすべてを、冪等性を維持しながら デプロイするのは非常に困難 ─ 些細な変更ごとに多大な時間をかけてデプロイしなければ ならない ─ ライトウェイト・カーネルが検討されるものの流行らず 11
  12. 12. Dockerの登場 • Dockerは単に仮想化技術としてのコンテナを実装した ものではない ─ コンテナと周辺の環境を統合的に提供している ─ クラウド時代の次にくる、新世代の開発環境基盤を目指し ている • Dockerは発展途上である ─ Dockerはここ数年で非常に伸びているが、変化も大きい ─ Kubernetesの登場でスタンダート化の道筋が付いたが、不 確定要素も多い 12
  13. 13. ここまでの(ちょっと強引な)まとめ • Docker/Immutable Infrastructure ─ サーバをコンテナにまで最小構成化し、「コード」として 管理できるようにした ─ これにミドルウェアやアプリケーションをインストールす る工程を加え、デプロイするまでを一括管理 ─ ひとつひとつのコンテナは「マイクロサービス」を担う →スケールアウト/マイクロサービス化 • Kubernetes/Infrastructure as Code ─ コンテナをクラスタ化する ─ クラスタを構成するためのノード(サーバ)を管理する ─ コンテナを収容するノードを選び、計画し、実行する(ス ケジュールする) ─ サービスを継続するための様々な機能を実装する 13
  14. 14. 事例1 14
  15. 15. インストーラ代わりのdocker-compose • レガシーなインストーラといえば; ─ ./configure ; make all; make install • 最近のアプリはdocker-composeを付けて配布 ─ サーバ構成とシステムデプロイを一括実行 • 具体例 - mastodon ─ オープンソース版Twitterとして2017年4月にブームに ─ 個人のインスタンスの他、Pixiv、dwangoの企業インスタ ンスが多数のユーザを集め話題に ─ Twitterの厳しいアカウント制限と重なり、イベントも多く 開かれた 15
  16. 16. サービス規模 サイト ホスト ユーザ数 mstdn.jp(個人) さくらのクラウド 178,000 pawoo.net(Pixiv) AWS 402,900 friends.nico(dwango) AWS 64,600 16 • 3サイトとも、インストール時点でコンテナを剥がし ている • 「レガシー」なサーバ構成と分散技術でスケールアウ トしている 2018年8月現在
  17. 17. Mastodonのシステム構成 17 実際運用してみてわかった、大規模Mastodonインスタンスを運用するコツ Shunsuke Michii, 2017
  18. 18. AWS上の物理構成例 18 実際運用してみてわかった、大規模Mastodonインスタンスを運用するコツ Shunsuke Michii, 2017
  19. 19. Pixivさん曰く 19 実際運用してみてわかった、大規模Mastodonインスタンスを運用するコツ Shunsuke Michii, 2017
  20. 20. 事例1:まとめ • 実運用に際して「剥がしてしまう」ケースはよくある • コンテナ運用に不安を抱くエンジニアは決して少なくない ─ スケールアウトさせるにはどうすればいいか分からない ─ どの程度のサイズで、どの程度収容できるか見積もれない ─ トラブル時に十分な対応ができるか自信がない ─ 結果、やむを得ずレガシーにやる • 大規模MastodonインスタンスはDockerに戻るか? ─ 戻らない(戻れない) ─ 「レガシーをコンテナ化する」という従来の問題になっている ─ 運用主体がそれを望んでいるように見えない ─ 開発が主眼ではなく、安定運用が優先だからではないか? ※個人的な感想です 20
  21. 21. 事例2 NETFLIX 21
  22. 22. NETFLIXがコンテナを導入した理由 • NETFLIXはVMでも満足していた ─ 可用性が高く、マイクロサービス化していて、クラウドネ イティブであり、CI/CD DevOps化もできていて、スケー ラブルだった ─ Chaos Monkeyでも有名 • それでもコンテナを導入したい ─ 絶え間ない開発と、継続的なリリース ─ アプリケーションの依存関係の簡素かつ完全な管理 ─ シンプルな方法でリソースを表現し、システム管理を可能 にする • 例えば、エンコード研究ではVMだと1ヶ月かかる工程 がコンテナであれば1週間になる 22 https://www.slideshare.net/aspyker/reinvent-2016-container-scheduling-execution-and-aws-integration Andrew Spyker, 2016
  23. 23. オーケストレーションツールを自作した理由 • NETFLIXのコンテナマネジメントプラットフォーム 「Titus」 ─ 多くのツールは「データセンター向け」だった ─ 「物理」と「クラウド」の両方に対応しようとしていた ─ クラスタマネージャ以上のものを提供しようとしていた ─ スケーリングのレベルが十分でなかった • NETFLIXが必要とするクラウドプラットフォームにス ケールさせる必要があった • (よくわかる!) ─ さくらのクラウドも自作基盤 23 https://www.slideshare.net/aspyker/reinvent-2016-container-scheduling-execution-and-aws-integration Andrew Spyker, 2016
  24. 24. Titusの実体:バッチの例 24 https://www.slideshare.net/aspyker/reinvent-2016-container-scheduling-execution-and-aws-integration Andrew Spyker, 2016
  25. 25. Titusの実体:システム構成 25 https://www.slideshare.net/aspyker/reinvent-2016-container-scheduling-execution-and-aws-integration Andrew Spyker, 2016
  26. 26. Titusにおけるサービスの定義 26 サービスとは長時間動いている バッチに過ぎない、だろ? https://www.slideshare.net/aspyker/reinvent-2016-container-scheduling-execution-and-aws-integration Andrew Spyker, 2016
  27. 27. もちろん実際はもう少し複雑 • サービスは常に変化し、永遠に動き続ける ─ オートスケーリング ─ 基盤となるホストをアップグレードするのは難しい • サービスは状態(ステート)を持っている ─ トラフィックに対処すること VS 単に起動/停止すること ─ サービスをアップグレードするのは更に難しい • 既存の開発体制やリリース体制、ランタイムや運用 ツールとの調整 27 https://www.slideshare.net/aspyker/reinvent-2016-container-scheduling-execution-and-aws-integration Andrew Spyker, 2016
  28. 28. 事例2:まとめ • NETFLIXの事例が注目を浴びた理由 ─ 1週間当たり300万のコンテナを起動した(2018年4月) https://www.publickey1.jp/blog/18/netflixtitus.html ─ 多くのコンテナを実運用で利用していることの驚き • 運用のためではなく、開発のために導入した ─ クラウドネイティブにおいて、コンテナ導入は自然な流れ と考えている • 巨大なサービスにおいて顧客を満足させ続けるために は、この流れは不可避なのかもしれない 28
  29. 29. サービス開発における コンテナの 意味 29
  30. 30. 現代のサービス開発と運用における課題 • スケーラビリティ ─ 開発時には小さく、リリース時には大きくしたい • 高い可用性、信頼性 ─ 「絶対に落ちないサーバ」ではなく「落ちてもサービスが 停止しない仕組み」が重要 • 容易な保守、運用 ─ 職人芸ではなく、コードベースで管理し、コードでメンテ ナンスする コンテナはこれらを解決するか? 30
  31. 31. スケーラビリティ • スケールアウトは必須のテクニック ─ 急激に増加・減少するユーザ数に対応する必要がある ─ スケールアウト対応は、結果的に可用性の向上になる • だがスケールアウトには一定の困難と複雑さを伴う ─ 分散処理とステートの管理が課題になる ─ 「コンテナ化したら簡単になる」わけではない • スケールアウトできない要素もある ─ データベースやロードバランサなど ─ コンテナが苦手とする要素でもある ─ スケールアップするか、サービスに頼るしかない ─ ロックインされてしまうこともある 31
  32. 32. 可用性・信頼性 • 絶対に落ちない1台のサーバから、100のうち30が落 ちても平気なサービスにする • スケールアウト(分散化)が、可用性・信頼性向上に 繋がる • コンテナはより適したソリューションになりうる ─ なにより早く起動できる ─ ImmutableかつCode化されたInfrastructureとして、管理 しやすくなる • しかしインフラだけでなくアプリも対応して作る必要 がある 32
  33. 33. 容易な保守・運用 • Infrastructure as Codeは運用を楽にするか? ─ データセンターへ駆けつける手間はなくなったかもしれない ─ コード保守化されたことも大きなメリットだろう ─ しかし保守・運用の本質はそこではない • たとえば監視業務 ─ Immutableなコンテナを監視するには、監視の仕組みも大きく変 えなければならない ─ 監視サーバからの外形監視ではなく、コンテナから状態を発信さ せて受け取る形へ変える必要がある • 障害対応も大きく変わる ─ 状態を保存することが難しくなる ─ 結果、原因調査も困難になりうる ─ 新しいテクニックが必要になる 33
  34. 34. コンテナは時代の流れ 34 https://www.slideshare.net/zembutsu/container-and-cloud-native-overview-distribution Masahito Zembutsu, 2018
  35. 35. どのサービスを利用するべきか? • AWS: ECS (Elastic Container Service)、EKS (ECS for Kubernetes) • Azure: AKS (Azure Kubernetes Service) • Google: GCP (Google Cloud Platform)、 GKE (Google Kubernetes Engine) • クラウドベンダー独自規格は一定の水準にある ─ 一方でロックインの問題がある • 業界標準はKubernetesへ進んでいる ─ ポテンシャルは未知数だが、日進月歩で進化している 35
  36. 36. マネージドvsセルフホスティング • セルフホスティング=自分でマスターノードを立てる ─ マスターのメンテナンスを含め、全ノードを自分で管理す る必要がある • セルフホスティングであれば全権利をコントロールで きる ─ 一方でスケールの調整も自分で行わなければならない • サービスもレベルが一定ではない ─ マスターのみマネージドで、ノードはサーバをレンタルし なければならないケース ─ サーバもマネージドだが課金はノード単位であるケース ─ フルマネージドのサービスはまだ少ない 36
  37. 37. まとめ • すでにクラウドネイティブで、コンテナ導入を検討し ている方: ─ コンテナの利点と課題を精査して経験を積んでいけば、強 力な基盤として活用していくことができるはず ─ コンテナへの転換ではなく、VMとの併用をすすめるべき • クラウドネイティブではないが、コンテナに興味を 持っている方: ─ 「クラウド」も「コンテナ」も銀の銃弾ではない ─ コンテナは黎明期で、飛びつくとやけどをする恐れがある ─ でも一足飛びに最新の開発手法…クラウドネイティブに追 いつくチャンスかもしれない 37
  38. 38. コンテナは次世代サービス開発の主流になるか? • コンテナの諸問題は5年程度で解決される • 2028年には「2018年ごろって、コンテナ無しでどう やって開発してたんですか?」って若者に聞かれるよ うになっている • コンテナを使わずにサービスを構成するのは趣味の問 題になっていると考える ─ 現代においてオンプレに拘るのと同等の意味合いになって いる • コンテナはサービス開発の主流になる - いやでも 38
  39. 39. おしまい 39

×