この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんばんわ、札幌のヨシエです。 AWS Summit Tokyo 2019 3日目のI3-06で行われたセッションのレポートを書きましたのでご査収頂ければと思います。
登壇者
株式会社ウエディングパーク メディア開発本部 技術責任者 西脇 靖紘(@yasuhiro1711)
ウエディングパークでは、複数サービスをオンプレから AWSへの移行を進めています。 コンテナでの実現を目指しており、それに際して比較検討、そして決定した過程をお話しします。
- マイクロサービスを見据えたクラウドベンダーの比較選定
- ECSか、EKSか、どちらを選ぶべきなのか？
- オンプレからAWS移行のポイント（仮）
登壇資料
AWSとその他クラウドベンダーとの比較選定してみた
- 組織として、約15年オンプレ運用していた
- 新規サービスは既に全てクラウドで構築していた
- 社内でのクラウドへの機運が高まったことで各クラウドベンダーの比較選定を行った
課題
そもそもの課題としては3つの課題を抱えていた
- サーバー納期/インフラ設定変更のコストが大きいこと
- セキュリティ作業のコスト
- 共有システムのSPOFのインパクト増
- アプリケーション開発の影響範囲に関する千疋
これらを解決するべく、数点の方針を出して比較検討を進めた
- STEP1：クラウド化
- STEP2：コンテナ化
- STEP3：マイクロサービス化
クラウドベンダーの選定ポイント
責任共有モデル
- AWSが打ち出している「責任共有モデル」でAWS担当のレイヤーに対する信頼性がどのレベルなのかを検証した
- 他クラウドベンダーと比較し、インフラの耐障害性と高可用性に注目をした
- Availability Zoneは複数のDataCenter異常(一つ以上)の面で耐性が高いと判断した
- Availability Zone間のNWレイテンシーも非常に低いので遅延を感じないところがポイントだった
- また、Amazonの研究開発費用ランキングも注目しており、よりよいサービス開発を考えていると考えた
セキュリティ/コンプライアンス
- AWSが守っている/対応している法律や規制といったセキュリティ・コンプライアンスが気になった
- AWS側でユーザー管理やアクセス管理などコンプライアンスをクリアしていたので社内の監査ポイントをクリア出来るところがメリットとして考えた
サーバーレスのパフォーマンス比較
- 自社開発を行ったアプリケーションで徐々に負荷を上昇させた結果、複数のテストでLambdaの性能が高い結果を表した
情報技術領比較
- Qiita,GitHubリポジトリ数がトップであることから、ナレッジ面に対しても懸念が払拭された
ここまでのまとめ
- AWSの研究開発費、サービスへの投資率の暑さがスゴい
- セキュリティ/コンプライアンス準拠の厚さがスゴい
- AWSのサーバーレスサービス品質の高さはスゴい
会社との相性を考慮したとき、既存サービスはAWSで利用している割合が高く、知識面の人気度は社内エンジニアNo1だったので
組織への導入コストは低いと判断した。
そしてコンテナ化をAWSで進めることを検討した
コンテナサービス理解とEKS・ECS
コンテナの特徴
- ポータビリティ
- どんな環境でも一貫した動作が出来るよう設定を環境変数にして依存関係とともにパッケージ化出来る
- リソースの利用率向上・効率化
- コンテナにプロセス分離することで、CPUやメモリの使用率を細かく設定できた
- 高速拡張
- OSのシステムリソースとは別プロセスなのでコンテナ起動停止は早い
なぜ選ばれる？
- 開発リリース(デリバリの高速化)
- 解決方法
- マイクロサービスの実現で解決
- マイクロサービスを実現するためにコンテナは必須だった
- 次にコンテナ環境に置く場所(環境を調査した)
- ECS on EC2がトップだった
コンテナだけでの運用は厳しい
- アプリケーションのデプロイ時にサービス継続、ロールバックの挙動
- スケール対応
- 複数リージョンに負荷分散したい
- これらを実現するためにコンテナオーケストラレーションが必須だった
コンテナで必要な技術
- アプリケーションのステートレス化開発 -アプリケーションをステートレスなアプリケーションに回収
- コンテナイメージの配置レジストリの利用
- どこにコンテナイメージを配置するべきか
- コンテナオーケストラレーションツール
- コントロールプレーンを考える
- ECS? EKS?
- データプレーンを考える
- EC2? Fargate?
- コントロールプレーンを考える
- CI/CDパイプライン
- デリバリーまでのワークフローで重要になる
考慮されたコントロールプレーンサービス
- コントロールプレーンとは？
- コンテナを管理をする司令塔
- コンテナ,VPC,ELBなどのコンテナを起動する場所を管理
- コンテナの起動やスケール対応、起動停止の管理
- コンテナ数(オートスケール)の管理
ECS
- 2015年からDocker SwarmやApache Mesosなどと異なる独自ソリューションとして登場したオーケストラレーションツール
EKS
- AWS上でKubernetesを実行するマネージドサービス
考慮されたデータプレーンサービス
- コントロールプレーンに従って起動停止を行う
- データプレーン上のコンテナで行った出来事(コンテナ異常など)をコントロールプレーンにフィードバックする
EC2
- 安価なインスタンスタイプやGPUを搭載したインスタンスタイプを選択することが可能
- スポットインスタンスを利用することが出来る
Fargate
- サーバーの管理概念をなくしている
- 現在、ECSのみ対応しており、単価が高かったが値下がりした
なぜAWSにはECSとEKSの2種類があるのか？
回答1：Kubernetesの台頭がすごい
- エコスシステムのコンテナオーケストラレーションとして台頭している
- 2017年にデファクトスタンダードとなっている
- コンテナエコシステム(layer構成)
そもそもKubernetesとは？
- コンテナアプリケーションを大規模管理、デプロイ出来るOSS
- yaml管理が出来る
- オンプレでもクラウドでも使える
そもそもEKSとは？
- ユーザーの要望によって、EKSが作られた(EC2 + Kubernetes)
- 複数AZで運用しており、SPOFがデータセンター単位で排除して可用性が高い
- IAMで認証管理やVPCやALBが使用できる
- 数点課題がある
- クラスター作成時間が長いことが気になる
- GUIでの操作は改善の余地があると思われる
- EKSはクラスター料金が発生する
回答2：ECSが優秀
- ECSとEKSの比較を行った
- Windows利用を利用する場合、「ECS + EC2」が一択だったものの、5月発表で変わりつつある
- 個人的に機能豊富の組み合わせが出来る
- ECS Fargate ではEC2を気にせずにコンテナ運用が出来る
- スケールもCPUとメモリのみを管理することでわかりやすい
- EKS(EC2)やEC2 + Kubernetesが使える、GPUインスタンスも使えるので特定用途に対して特価した使い方が出来る
- EKS(fargate)はまだ未対応、今後の登場に期待
Q.KubernetesがデファクトスタンダードならばKubernetesが使うほうが良いのか？
- A.そうとも限らず、状況に合わせて選べば良い
- Kubernetesの盛り上がりはスゴいが、本番運用では普通のコンテナが多い
棲み分けを整理した
ECS
- 運用が用意
- 低コスト
- AWS側から大規模サービス向き(非公式)
- 可用性を十分考慮できる
- Fargateが使える
- アプリケーションエンジニアへの敷居が低く、スタートアップなどで選択されやすいと思われる
EKS
- Kubernetesのエコシステムが使える
- AWSサービスとの連携を使える
- Kubernetesを使える組織であればこちらが良い
まとめ
- ECSまたはEKSといったコンテナオーケストラレーションは運用システムの設計や特性などワークロードによって選択することが重要
- Kubernetesの学習コストが高くなりがちなので、サービスのスピード感と対応エンジニアのスキル面も考慮ポイントに入れても良いと思われる
- マルチクラウドでサービス提供予定ならば、EKSが良いと思われる
ウエディングパーク様では3つのステップで検討を行った
知る→比べる→決める知る
- Kubernetesを自宅で作成した
- AWSの公式トレーニングをやった
- AWSのワークショップを実施
比べる
- コントロール/データプレーンをそれぞれ星取り表とメリデメを比較検討を実施
- コントロールプレーン(コンテナオーケストラレーションツール)の選択
- ECS or EKS
- データプレーン
- EC2 or Fargate
- コントロールプレーン(コンテナオーケストラレーションツール)の選択
- Kubernetesの導入はありかなしか
- Kubernetesは魅力でネームバリューがある
- だからといって進めないほうがよい
- 初期の学習コストやバージョンアップに伴うAPIの運用コストを考慮すると総コストが高くなる懸念があった
- 設計メンバーの影響が大きくなり、Kubernetes運用を別チームに引き継げるのか懸念が発生した
- Kubernetesは魅力でネームバリューがある
決める
構築、運用面の比較結果結果
- ビジネスファーストとして、ECSから初めた
- 理由としてはKubernetes導入よりもビジネス拡大を優先
- ECSにてサービスを提供し、何かしら不自由な部分が目立った時にEKSへの移行で問題ないと考えた
これからの未来
- サーバーレス・コンテナ・プラットフォーム
- サーバー管理が不要、かつEC2と同様のことが出来るコンテナプラットフォームをイメージ
- より、簡単に設定など運用を実現できる
- コンテナオーケストラレーション管理は複雑なものから→簡易になる
- コンテナエコスシステムが中心になると思っている
- サービス事業者は「サービス開発事業に集中する」事が実現出来ると考えている
- このために、コンテナ運用にはオーケストラレーションツールが必須で周辺技術を含めて知識を得る必要がある
- エコシステムのKubernetesの可否は目的と学習コストで考える
- ECSは他にはない導入が簡単なソリューション
最後に
AWSを選択した理由とAWS上でコンテナ環境を運用する際に選択肢として出てくるEKSやECSに関して深い考察を含んだセッションでした。 コンテナ自体を動作する環境やオーケストラレーションツールは悩みのタネとして上がることが多く、環境検討で躓くパターンもあるかと存じます。 その点でどういった形でコントロール/データプレーンを選択するべきなのかについて参考になったセッションでした。 もし、コンテナ化を検討する際はコンテナ基盤に対して求める点を整理することが一番重要かと思います。
40
