今週からコンテナやるぞ！と思っていたら金曜日の夜になっていた。そんな多忙なエンジニアライフを送っていませんか？この記事では、多忙すぎるエンジニアであるアナタに向けて、それでもコンテナ学習をやるべき理由をご紹介します。
このようなシチュエーションに該当する方は、ぜひご一読ください。
- インフラ管理に忙殺されている
- AWS・Azure・GCPのいずれかでVMを運用している
- DockerとKubernetesどちらから始めるか迷っている
はじめに: DockerとKubernetes、どれから始めれば良いの？
最近は国内のテック系メディアにもKubernetesの採用事例や周辺ツールの紹介記事が増えてきました。官公庁の案件でもインフラ要件にKubernetesというワードが散りばめられている時代です。しかし、DockerとKubernetesどちらから始めるか迷っているなら、Docker一択です。
その理由は、
- Dockerを覚えると、コンテナイメージの作成・起動・オーケストレーション操作を一通り実現できる
- Kubernetesにはコンテナイメージを作成する機能が無く、結局Dockerが必要になる。構成要素が多く選択肢も多いためインフラ予備知識を持っていないと行き詰まる
つまり、初学者にとってKubernetesとは「Dockerを学んでから利用検討するツール」であると言えます。また、Dockerは「誰でも使えるLinuxコンテナツール」としてデビューしましたが、KubernetesはGoogleのサービスがスケールしすぎて従来のインフラ管理技法の限界に突き当たっために発明されたテクノロジーです。存在理由が違うのです。
限られた時間で効率良くコンテナ技法を身に着けましょう！
理由 1. クラウドのコンテナ系フルマネージドサービスが使える
少数精鋭のチームに属しているエンジニアは、アプリケーションとインフラどちらの管理責任も負っていることがあります。本番環境でアプリケーションのバグが突如発現したり、トラフィックが多すぎてサーバダウンするなど、あらゆる問題に対応し続けるのは容易なことではありません。コンテナ系フルマネージドサービスを駆使すると、インフラの管理スキームを抜本的に変えることができます。
フルマネージドサービスとは、クラウド事業者がインフラの常時監視や障害復旧を担っているサービスの総称です。要するに、クラウド事業者がインフラを24時間365日体制で稼働/メンテナンスし続けてくれるということです。コンテナを使っていなくてもAWS RDSでデータベースを運用しているなら、既にフルマネージドサービスのメリットはご存知だと思います。
Dockerを使うと、コンテナ系フルマネージドサービスを利用できます。例えば、AWSのコンテナ系フルマネージドサービス群はこのようになっています。
- Fargate: フルマネージドVM
- Batch: フルマネージドなバッチ実行環境
- ECR (Elastic Container Registry): フルマネージドなコンテナレジストリ
- ECS (Elastic Container Service): フルマネージドなオーケストレーションサービス
- EKS (Elastic Kubernetes Service): フルマネージドなKubernetesサービス
これら複数のサービスを組み合わせると、リリースプロセスは以下のように進行します。
- アプリケーションと依存関係をDocker Imageに封入して、コンテナレジストリにPushする
- オーケストレーションサービスに配備指示を出すと、オーケストレーションサービスがコンテナレジストリからDocker ImageをPullし、起動処理を実行する
- コンテナが起動する
「新しく覚えることが多くて大変そうだな。。」と思いましたか？記事を読み進めると、コンテナ化のさらなるメリットをご確認頂けます。
理由 2. サーバレスでランニングコストを抑えられる
サーバレス、実はコンテナにも対応し始めています。
GCP Cloud Runを使えば、コンテナをPushするだけでWebアプリケーションを公開できます。AWS ECSやGCP EKS等のオーケストレーションサービスはコンテナを起動するための「指示出し」が必要なのですが、サーバレスはよりシンプルで、トラフィック状況に応じて自動的にスケールしてくれます。
リクエスト課金の魅力
さらに価格体系がリクエスト課金ということも大いなるメリットです。サーバレスの特性上、HTTPエンドポイントにリクエストが届いた時だけコンテナが起動し、レスポンスを返した直後に破棄されるので、処理に要したリソース（CPU/Memory/Network等）の利用料金を支払えば良いのです。
イマドキのWebアプリケーションは1回のレスポンスを長くとも数秒で返すように実装していると思いますので、リクエストが少ないQA環境やステージング環境の維持費が爆安になります。リクエストが少ないアプリケーションなら、本番環境を含めても無料枠に収まります。
ステートレスの制約
ただし、これらのサーバレス処理を行うためには、Webアプリケーションをステートレスに実装しておく必要があります。ステートレスとは「状態を持たない」ということで、例えばログインセッションをコンテナ内部ではなくRedis等の外部データストアに格納し、どのコンテナから参照しても常に同じデータソースに辿り着ける仕組みを実装しなければなりません。
逆に、コンテナ内部にログインセッションを格納するなら「ステートフル」であり、これはコンテナの更新時にデータが抹消されるためバッドプラクティスです。コンテナがステートを生み出してしまう場合は、外部のファイルストレージやデータストアに格納しましょう。
理由 3. VMの煩わしさを一掃できる
コンテナをフルマネージドサービスで運用することに慣れると、これまでVMのセットアップに費やしていた時間が煩わしく感じるようになります。なぜなら、クラウドにVMをセットアップする時には以下のようなオペレーションが必要になるからです。
- OSの選定
- VMの起動
- Firewall設定: 主にポート開放や固定IP制限
- SSHキー設定
- パッケージアップデート
- アプリケーション配備
このオペレーションの問題点を考えてみます。
SSHキーや固定IPの設定が煩雑
原始的なVM運用の場合、プロジェクトメンバーが増える度にSSHキーを払い出すか、メンバーのSSH公開鍵を聞き出してVMに登録するという作業が発生します。この作業が面倒なので、SSHキーを使い回しているプロジェクトを過去何度も見てきました。
また、プロジェクトメンバーに渡したSSHキーが適切に管理されているかを把握することは困難です。同様の問題が固定IP設定にもあり、誰のためにポート開放したのかが分からず「怖くていじれない」という状況に陥っているプロジェクトは多いと思います。
複数のVMのステートを同期させるのは難しい
VM運用で最も厄介なのが「VMはステートフル」ということです。VMにアプリケーションをデプロイするというのはVMの内部状態を書き換えることなので、もし不具合が発生した場合のロールバックが困難です。
例えば本番環境で apt update したらOpenSSLがバージョンアップされて、アプリケーションが通信障害が起きたら、問題特定とロールバックに時間がかかることが想像できます。VMが2台ならまだしも、100台構成の一部に問題が発生したら。。（以下略）
これらの諸問題を回避するためにBlue-Green Deploymentやカナリアリリース等のリリース手法がありますが、コンテナでやった方が楽です。
コンテナ to Rescue
VM運用に課題を抱えているチームこそ、フルマネージドなコンテナ運用が向いているかもしれません。それは、コンテナには全ての依存関係が封入されていて、かつ不可変だからです。コンテナにステートを持たせないようにアプリケーションを実装しておけば、VMの諸問題は根こそぎ解消できます。
先述したVMのオペレーションをAWS ECSとFargateの運用スキームに置き換えてみます。
- OSの選定 → VMと同じだが、ローカルマシンで全く同じバージョンで動作検証できる🎉
- VMの起動 → フルマネージドサービスに任せられる🎉
- Firewall設定 → 不要🎉
- SSHキー設定 → 不要🎉
- パッケージアップデート → Docker Imageに封入できる🎉
- アプリケーション配備 → フルマネージドサービスに任せられる🎉
これまで費やしていたリソースを「コンテナ化」に一点集中させて、コンテナの恩恵を享受してください！
まとめ
コンテナを導入すると、ヒト・モノ・カネのコストを削減して、本来の目的であるアプリケーション開発に注力できるようになります。
- クラウド各社のコンテナ系フルマネージドサービスが使える
- サーバレスでランニングコストを大幅削減するチャンスがある
- VM管理の煩わしさから開放される
これらはコンテナ導入メリットの一端で、まだまだ沢山の旨味があります（いずれ記事を書きます）
Dockerが登場したのは2013年、AWSがECSを発表したのは2014年です。相当な時間が経っていますが、それでも国内にはコンテナ技術に精通したエンジニアがほとんどいないと感じます。Dockerでコンテナ周辺知識を蓄えながら、あなたのエンジニア市場価値をさらに高めてはいかがでしょうか。
サイオステクノロジーでは、DockerやKubernetesを効率的に学習できる独自のトレーニングサービスを提供しています。私もトレーニングの教材開発と講師をやっていますので、モダンなインフラストラクチャやチームビルディングにご興味のある担当者様、ぜひご連絡をお待ちしています！
著者について
Instoll株式会社 CEO 友田敬人 (Twitter, GitHub)
自動化を愛するフルスタックエンジニア。最近は主にインフラアーキテクトとしてサイオステクノロジー社のプロジェクトに参画中。 AWS・GCP・Azureを適材適所で組み合わせながら、マルチクラウドをInfra as Codeで管理するのが得意です。
