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