ベーシック アドベントカレンダー 12日目です。
306 と申します。
ベーシックでは主にインフラを担当してやっています。
皆さんは、本番環境をコンテナで動かしていますでしょうか？
弊社でも今年に入り、本番でもコンテナを使うようになってまいりました。
弊社における初の本番環境がコンテナで動く Webサービス は
結婚相談所比較ネットになります。
これは、ECS on Fargate を採用しております。
ベーシックでは現在 8つ のWebサービスを運用しています。
この内 2/8 が本番でもコンテナで稼働しており、
EKS on EC2 と ECS on Fargate で動いています。
これは私がインフラを担当しています。(EKS は途中から担当)
そして、1/8 が一部 EKS on EC2 で動いている状態です。
そして、来年には全てのWebサービスをコンテナに移行できるように進めています。
(既存の EC2 が Amazon Linux(1) ということもあり丁度移行をすすめるきっかけとなりました)
今日はコンテナ移行していく中どういった、サービスを選択していくか
これまでの運用経験をもとにお話できればと思います。
前提として弊社ではインフラに AWS を採用しております。
なので今回は AWS においてどうやってコンテナを動かすかという話になります。
ご了承ください。
EKS と ECS / EC2 と Fargate
まず AWS でコンテナを動かす上で考えるべきは
- コンテナをどうやって指示して動かすのか(コントロールプレーン)
- コンテナをどこで動かすのか(データプレーン)
この ２つ を意識しないといけません。
ここらへん解説はクラスメソッドさんの記事が詳しいので読んでいただいて下へ読んでいただければと思います。
「それコンテナにする意味あんの？」迷える子羊に捧げるコンテナ環境徹底比較 #cmdevio2019 ｜ Developers.IO.html
上の資料について補足しますが、
AWS では Fargate というコンテナを動かす専用VMが存在します。
(ざっくり説明してます。厳密には違います)
少し前まで Fargate で動かす = ECS で動かすでしたが、
その考えは捨ててください。先日の re:Invent2019 で EKS on Fargate が発表され
EKS でも Fargate が利用可能になっています。
どのコントロールプレーンを使うか
AWS においてコントロールプレーンは ECS と EKS があります。
詳しい説明はクラスメソッドさんの記事に任せるとして
ここでは運用目線での違いを書きたいと思います。
ECS と EKS を運用に載せた場合、
EKSのほうが保守コストが大きいです。
前回の記事でも述べましたが、
k8s の開発のスピードが早く、3ヶ月に一回は新バージョンが出ており
今月も v1.17 が出ました。
EKS では現在 v1.14 まで対応してますが
EKSでサポートされ次第最新バージョンを使っていく必要があります。
これは、EKS のバージョンライフサイクルがそうなっているためです。
(1つのバージョンの利用可能な期間が約270日間しかないためです)
放っておくと強制的なアップデートが開始されます。
そのため事前にアップデートする保守コストが発生します。
一方ECS の方は AWS が独自に提供しているためか、
今の所コントロールプレーンでのアップデートによる
保守コストは発生しておりません。
そもそも ECS 自体にはバージョンと言う概念がないのでアップデートはないかもしれません。
もしかしたら裏でこっそりやっているかもしれませんが、わからないレベルで実現しています。
どのデータプレーンを使うか
AWS において、コンテナを動かすデータプレーンは EC2 と Fargate があります。
このうち EC2 を選択し場合は、 EC2 に対する保守運用コストが発生します。
コンテナ化なのに EC2 の保守・運用は必要なの？と思う方もいるかも知れませんが
例えば EC2 の場合、OS の導入まではAWSの責任で
そこから先のコンテナを動かす部分は、自分たちの責任となります。
ecs-agenet(or kubelet) や docker や ホストOS の脆弱性の対応等は
自分たちの責任であり、面倒を見なくてはいけません。
これが Fargate の場合、コンテナが動かせるところまで
AWS の責任にすることができます。
ecs-agenet(or kubelet)や docker や OS の面倒は
すべてAWSに投げられるようになるため、保守コストが圧倒的に減ります。
またSSHもすることができませんし、 Fargateのホストに入ることも不可能なので
EC2 に比べてセキュリティという面でも向上するかと思います
また Fargate の場合、動かしたいコンテナの数を指定するだけで、
コンテナの数だけ、マシンが稼働してくれるので
コンテナを動かすEC2のキャパシティのことを考えなくてよいのも利点です。
(re:Invent2019 の発表でキャパシティの問題は EC2 でも解消されました)
個人的な技術選択フロー
弊社にしてコンテナサービスに移行する前に大事にしていることは
どれだけ保守コストを削減できるかということです。
弊社では、Webサービスを提供してそこで利益を出しています。
となると、弊社エンジニアが本来注力すべきところは、Webサービスの改善であり、
つまり アプリケーションコードを書くことにより注力できるインフラ を構築するということです。
yum update を自動化してもそれはサービスの改善には繋がりません。
もちろん保守やセキュリティリスクを担保する上では大切ですが
手間のかかる行為でなくせるものなら、なくしたいものです。
また自動化しても、突然のアップデートで config が
読み込まれずにサービスがダウンするといったことがありえます。
また Webサービスの特性上、突発的なアクセス増加もありえます。
そういったアクセス増加に対して即座にサーバーを増やす事も考えないといけません。
コンテナ化以外でもこれらの問題は解決できますが、
コンテナ化して問題の解決を楽にすることはできると思っています。
そんな中で私だったらどの順番でコンテナサービスを決めていくのか
ランキング形式で紹介したいと思います。
この基準は、ベーシック開発部の全体での意見ではなく、あくまで個人の独断で基づいたランキングになります。
第一位 ECS x Fargate
まず1番に選択するのは ECS x Fargate の組み合わせです。
理由はとてもシンプルで保守コストが一番少なくなるためです。
第二位 ECS x EC2
2番目に選択するのは ECS x EC2 の組み合わせです。
Fargate では対応できないような案件が来た場合は EC2 を使うことになります。
強いコンピューティングリソースを使う場合や、何かしらの要因で、ホストマシンが必要なケースです。
第二位 EKS x Fargate
同じく2番目に選択するのは EKS x Fargate の組み合わせです。
ECS では難しいようなインフラアーキテクチャーでは EKS を採用します。
EKS は k8s そのものなので、柔軟な環境が作ることが可能です。
コントロールプレーンは Fargate を採用するので、Node の保守コストが削減できます。
第四位 EKS x EC2
最後に選択するのは EKS x EC2 の組み合わせです。
インフラアーキテクチャーが複雑かつ、
Fargateで動かすことができないワークロードで使います。
保守コストはこの中では一番かかりますが、
EC2でそのまま動かしていた頃に比べると
保守コストは圧倒的に減ります。
まとめ
コンテナ時代の技術選択は常にアップデートされており、
ここで書いてたものも明日には役に立っていないかもしれません。
絶対にこの技術を選択が正しいんだ！と思わずにいろんな要因を考えながら
技術を選定してもらえればと思います！
今回の記事でコンテナ技術の選択のお役に立てばと思います。
最後まで読んでくださり、ありがとうございました！
photo by Rinson Chory