コンテナ化＆インフラ移行の事例紹介（ランチMTGでの発表資料）

お世話になっております。株式会社e2infoのEC2アンチ担当、インスタンス削減太郎と申します。

突然ですが、弊社ではランチMTGというちょっとした勉強会があります。先日、その機会に、私が担当していたプロジェクトの事例紹介を兼ねて「コンテナ運用したらいっぱい利点があった」という内容を発表しました。

AWSを使っていれば、データベースには Amazon EC2 ではなく Amazon Aurora (Amazon RDS) を利用すると思います。ロードバランサも、EC2ではなくALBを使います。それと同様に、Webアプリケーションも汎用サーバーのEC2ではなく、AWS Fargate で運用するべきです。

……というような内容の発表でした。せっかくなのでブログに投稿します

プロジェクト概要

詳しいプロジェクトの話は省略しますが、一言で言うと「EC2で運用されていたRailsアプリケーションを、コンテナ化＆インフラ刷新する」というプロジェクトでした。

スケジュールとしては、このような感じでした。

結局のところなにやったの？というスライドがこちらです

コンテナとは

本発表のメインテーマ「コンテナ運用は利点がいっぱい！」という話をするにあたって、エンジニアでないメンバー向けに「コンテナとは何か」という話を挟みました。当初は「幕間」としておまけのつもりでしたが、発表時間の都合もあり今回のテーマの1つになりました。釈迦に説法かと思いますので、この記事ではスライドの紹介のみにとどめます。

この図だけでは直感的でなかったので、Geminiに「クッキー作り」の例えのための図を描いてもらいました。

コンテナ運用のここが良い！

少し強引ですが、コンテナの概要を理解してもらったということでさっそくコンテナ運用の良かったところの紹介に入ります。

コンテナ運用で得られるメリットは、やはり手作業が減る利点が大きいです。少々恣意的ですが、コンテナを使わない場合の手順と、コンテナを使った場合の手順で比較するとこうなります

手作業が減ると何が良いのかというと、説明不要かもしれませんが効率性や安全性が向上します。

手作業が減るのは特に構築フェーズの話なのですが、運用フェーズでも利点が多くあります。最大の利点は、コンテナ化ではなくサーバーレス化の利点ですが、管理スコープの縮小です。

OSを管理しなくてもよく、アプリケーションに集中できるようになることで運用の負担が減ります。セキュリティや安定性も向上します。

さらに、再現性が高くなることや、ミドルウェアの設定もGit管理できるようになるのも大きな利点です。

コンテナ運用の注意点

コンテナ運用にはあらゆる利点があります。極論、EC2で運用しているサービスを全てFargateに移行してしまってもいいんじゃないかと思います

しかし、もちろんそうはならない理由があって、移行作業自体のコストと、オペレーションが変わることによるリスクの２つが主なハードルとなります。

他にもコンテナ運用でのハードルはありますが、移行コストと慣れの問題以外は対策は可能な範囲かと思います。例えば、FargateのインフラコストがEC2よりも割高という欠点はあるのですが、Saving Planを使うとEC2のReserved Instanceと同等のコストで運用できるようになります。また、FargateではSSHできないですが、代わりとなるECS Execがあります。もっといえば、SSHを使わなくても調査できるようトレーサビリティ・オブザーバビリティを改善するのが望ましいです。

もう１つの問題として、コンテナ化にあたってはアプリケーションの対応も必要になります。

おまけのAWS CDKの話と、まとめ

今回の発表では「コンテナ運用ではこんなに良いことがあった！」という話を紹介しまして、もう1つの重要な技術スタックであるAWS CDKの話ができませんでした。AWS CDKを使うと、CloudFormationよりも柔軟にAWSのリソースをコード管理することができます。インフラ移行がスムーズに実施できたのは、このAWS CDKのおかげなので、次回はAWS CDKの話もできればと思います。