コンテナ利用事例と活用へ向けた取組み(iCARE Dev Meetup #17) | Dev Driven 開発・デザインチーム コンテナ利用事例と活用へ向けた取組み(iCARE Dev Meetup #17) | 働くひとと組織の健康を創る iCARE

BLOG

コンテナ利用事例と活用へ向けた取組み(iCARE Dev Meetup #17)

こんにちは!インフラエンジニアのずやです!

先日(1月20日)開催された スペシャリストから学ぶ、SaaSを支えるインフラ iCARE Dev Meetup #17 にて、「iCAREにおけるコンテナ利用事例と活用へ向けた取組み」という題でLTをしました!

今回は、その発表内容をブログとして公開したいと思います。

コンテナ利用の現状:主要プロダクト編

まず最初のトピックは、弊社の主要プロダクトであるCarelyのコンテナ利用事情です。

ローカル開発環境にはdocker-composeを利用しています。また、CIサービスとしてはCircleCIを採用していますが、CircleCIのjobのexecutorにもDockerコンテナを利用しています。
一方で、AWS上で構築しているQA、STG、本番等の環境は仮想マシン(AWSのEC2)を利用しています。

本番環境の簡単な構成についての説明と課題点についてです。
ごく一般的なWebアプリケーションの構成パターンですが、EC2インスタンスに関してはオートスケール構成ではなく固定台数のインスタンスを利用している形となっています。
そのため、保守・運用面での作業コストや費用の最適化が課題となっていました。

そこで、本番環境のKubernetes導入によるコンテナ化をすることで、スケーラビリティの確保やコスト最適化を図りました、、、

が、あえなく失敗に終わってしまいました。。。

失敗した要因としては、見積もりの甘さと作業リソースが確保できなかったことで進捗がストップしてしまったことです。また、たとえ移行がなんとかできても運用をしていけるのかという懸念もありました。

そして、そもそも最初の課題に対する手段としてコンテナ化が適切であったかと考えると、実際問題はオートスケール構成でないことなので、仮想マシンのままでもオートスケールさせれば十分です。工数や運用を考えてもコンテナ化よりリスクが低い(かつ期待する効果は得られる)と判断したため、現在はまずオートスケール構成への移行に着手しています。

では、逆にどういう場合にコンテナ化をするといいのか。仮想マシンでは難しくてコンテナだから良いという点を考えてみました。
1点目はデプロイの高速化です。コンテナのデプロイは、コンテナイメージの更新 → 稼働中のコンテナ(KubernetesであればPod)を洗い替え、となると思います。Podの起動は仮想マシンの起動とは比べ物にならないほど速いため、デプロイ時(ロールバックも同様)に高速でバージョンを切り替えられるわけです。
2点目マイクロサービス戦略をとる場合です。コンテナ化が唯一の選択肢ではないと思いますが、世に事例がたくさん存在しています。
3点目はコストの最適化です。特に複数のサービスを運用している場合、それらを共有のクラスタ上に展開することで、マシンリソースの配分を最適化できる可能性があります。
(残りの二つはエンジニアとしてのエゴです...。ただ技術はいずれ陳腐化していくので、これらを言えるのもあと2、3年くらいかもしれないですね)

コンテナ利用の現状:主要プロダクト編

次のトピックは、Carely以外のプロダクト(社内ツール含む)のコンテナ利用事情です。

結論:割とコンテナ化しています

背景としては、コンテナでの環境構築や運用のノウハウをためるという目的が大きいです。
また、0→1の場合には、仮想マシンで環境を作るよりも、コンテナ前提の方がスピードが出るケースが多いと感じています。ローカルの開発環境だと基本的にDockerを利用するので本番環境にもイメージを流用できる一方で、仮想マシンの場合は別途構成管理ツールのセットアップが必要になるためです。

以降では、実際にコンテナを利用しているプロダクトについて三つほど紹介します。

Carelyの製品紹介ページです。

VPoEのトシさんの愛が込められたアプリです(詳しくはこちら)。
Elastic Beanstalkの環境からEKSに移植しました。

データ分析用のBIツールとして試験的に導入している「Metabase」というOSSです。
こちらの記事に環境構築について書いています)

ここで、AWSにおけるコンテナ環境の選択肢の比較を簡単にまとめました。

まずコンテナオーケストレーションツールとしては、ECSかEKS(Kubernetes)の選択肢があります。
ECSはKubernetesに比べれば機能は少ないものの、その分シンプルで、ないものは他のAWSサービスで補うという設計のようで、他のAWSサービスとの連携が容易という点がメリットです。
Kubernetesはコンテナオーケストレーションツールとしてはデファクトスタンダードで利用者も多いため、広く知見を共有・利用することができます。

次にコンテナ実行環境として、EC2かFargateかという選択肢です。
EC2は安定の選択肢。
Fargateは、特にホストマシンの管理がいらなくなる点でメリットがあります。一方でEKSで利用する場合、Podの起動が遅かったりDaemonSetが使えなかったりなどの制約があり、一般的なKubernetesとは異なるノウハウが必要になり癖が強いという印象があります。

コンテナ活用へ向けた取組み

最後にコンテナ活用へ向けた取組みの紹介です。

一つは前トピックの内容の通りで、小さなサービスなどでノウハウをためるということで、もう一つはコンテナに関する勉強会の実施です。

勉強会はただ知識を習得するということ以上に、コンテナ便利でどんどん使っていこうというチームの雰囲気を作る、いわば文化作りの面が大切だと感じています。

KubernetesとDockerをメインに勉強会や輪読会を開催しています。

輪読では下記の本を題材に使っています。

Kubernetes完全ガイド
イラストでわかるDockerとKubernetes