この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんばんわ、札幌のヨシエです。
2/22に31歳になりますが、その誕生日プレゼントとしてJAWS Sapporoの運営メンバーから「コンテナに関して登壇」というプレゼントを頂きました。
ですが、情勢的にリモートでの登壇をさせて頂きましたので資料の公開を含めて本記事を書きました。
参加者の皆さんには音声が聞きづらかった部分が多くあったと思いますので本記事でお伝えしたかったことをかいつまんで書きます。
資料
コンテナについておさらい
コンテナとは
コンテナはサーバーリソースを共有してアプリケーションを実行するために必要なソースコードやライブラリなどを詰め込んだ箱になります。
コンテナ自体はサーバーのようにbashが使用できるといった振る舞いを見せるので、仮想マシンのイメージを持たれがちかと思いますが、コンテナはホストOSからプロセスとして起動するので仮想マシンとは大きく異なるものになります。
また、コンテナは仕組み(ライフサイクル)として容易に破棄することが出来る仕様があり、ログファイルやコンテナ上で行った処理の成果物の保存は永続化が必要になります。
ここは一見デメリットに見えますが、見方を変えると「状態」を持たせないということが技術上の仕組みとして提供されているので、この仕様をクリアするためには「データを外部へ転送/保存する」といった考え方が開発者の共通見解となるので保存方法に迷うことはなくなると思います。
ユースケース
盛り上がりつつあるコンテナですが、一部ユースケースを上げてみます。
マイクロサービス
マイクロサービス自体は小さいサービス同士を連携させて大きいサービスを提供することを指し、AWSではLambdaで作ることが先行しがちです。
Lambdaで作成することによってコスト面等が大きいメリットになりますが、コンテナを利用することで実行時間制限以内に処理が終わらないようなサービスに対しても対応できるようになります。
バッチ処理
バッチ処理は一般的にある程度の量を一括処理することを指す言葉として扱われます。
大量の小さいログファイルに対し、短時間に処理を行うには並列的に実施することが効率良いと考えられます。この並列処理を実現するためにコンテナを利用することで処理台数を短い時間で起動することが可能となり、かつ、一つのログファイル処理に適切とされるCPU/メモリといったリソースをコンテナに割り当てることが可能になることからリソース、コスト、時間の面で相性が良いユースケースと考えております。
サービスを提供している環境とのトラブルが発生しづらい
本番環境で利用されているコンテナイメージを開発者の端末へPullすることによって、同じアプリケーション、ミドルウェアが入ったコンテナを利用することが出来るのでバージョン差異によるトラブルが発生しづらいことが挙げられます。
また、流動的に開発者の異動があるような現場においてはDocker-composeと呼ばれる複数のコンテナで構成されるシステムをひとまとめに定義できるツールを利用することでオンボーディングへの所要時間を節約することが可能ではないかと思います。
良い使い方がわかる資料紹介
ここまでのお話でコンテナに興味を持って頂いた方には一緒にご紹介したい資料があります。
Twelve Factor App
Twelve Factor Appとはウェブアプリケーションを提供するにあたって、どのような姿で作られるべきかがまとまっている方法論です。
12個の点を留意してシステムを作ることで改善活動や効率的な運用を行うことが出来るようになります。
AWS Blackbelt「これから始めるコンテナワークロード」
内容はコンテナを業務等で使用するためにはどのようなアプローチを踏むかがまとまっている内容であり、構築から運用までがステップに分かれているので腹落ちがしやすい内容で書かれております。
濃い内容の資料なためコンテナを触り始めな方からコンテナに少し慣れた方まで勉強になるので、youtubeで視聴することをオススメします。(50分前後に動画ですがとてもタメになります)
私がコンテナを触り始めて思ったこと、分かったこと
触り始めの時は起動の速さには驚いたことを記憶してます。仮想マシンはおおよそ数分かかるところがコンテナでは秒程度で実行される感動は今でも忘れません。
コンテナではデファクトスタンダードとして扱われるDockerを使ってコンテナの起動停止を体で覚え、dockerfileを作ってコンテナにやらせたいことを少しずつ範囲を広げて練習しました。
コンテナに少し慣れてきた頃には自分の業務で利用するスクリプトをコンテナに入れ込んで使うようになりました。(業界的には慣れてきた頃をマスターと呼ぶらしいです)
当時を振り返ると仮想マシンは使わず、コンテナを積極利用するべきと盲目的になった時期がありました。 (適材適所を見極めて仮想マシン、コンテナ、Lambdaのように選択することが一番の正義です)
コンテナを本番環境で使うハードル
コンテナを本番環境で利用するには少しハードルがあると考えました。
それはコンテナを動かす場所の問題です。
一つのコンテナだけを動かしたいのであればEC2にDockerをインストールして使用することが出来ます。 しかし、ウェブサービスをコンテナで動かす際には大量のトラフィックを捌くためにスケーリングが必要になったりバージョンアップなどのメンテナンスが必要だと思いますが1台のインスタンスでは対応できません。
またコンテナに環境を変更するということはスケーリングなどの運用上で手間とされる作業を減らすことが目的になるため、コンテナを無理やり入れることは手間が増えることになるので本末転倒となります。
また、AWSサービスと連携を行えることも必要と考えております。
- トラフィック分散：ELBを利用したい
- コンテナ/コンテナホストのスケーリング：AutoScalingを利用したい
- 永続化データ保存：EFS/S3などのストレージサービスを利用したい
こういったことがハードルとして挙げられ、これらのハードルを乗り越えるためにコンテナオーケストレーションをお話しました。
コンテナオーケストレーションとは？
コンテナオーケストレーションの説明文でオートヒーリングについて質問を頂きましたので、回答を引用させて頂きます。
ECSとAutoscallingと連携させた際にその設定をStatic（MinもMaxももdesired同じ値）にした際には、仮に何かのIssueでコンテナが消えた場合、自動で設定された値にコンテナを戻します。これをオートヒーリングといいます。（オートスケーリングの1種）
EC2においてもオートヒーリングと呼ばれる言葉を使用する場合があります。
オートヒーリング＝スケーリングはせずインスタンス数の維持に利用する https://dev.classmethod.jp/cloud/aws/2018-aws-re-entering-autoscaling/
AWSでコンテナを使う選択肢
現時点ではこのようなAWSサービスでコンテナを利用することが出来ます。
AWSサービスのElasticBeanstalkでDockerを使用するケースはどのような場合があるか？という質問を頂きましたので、回答を引用させて頂きます。
BeanstalkはELBも含めて管理してくれる、という利点はあります。ちなみによく勘違いされますが、エラスティックビーンスタークです。(not ビーンズトーク）
また、説明部分でDockerが使用できる旨をお話しましたが、以下の回答が正確となります。失礼しました。
EB側の話になっちゃいますが、GlassfishやGoなどDockerを組み込むことで対応言語のラインナップを増やせた、という言い方もできるかなと思いました。
※はじめからElasticBeanstalkのことを「エラスティックビーンズトーク」と呼んでおりましたが、正確には「エラスティックビーンスターク」 でした。
ご回答頂いた方、ありがとうございました。これで今後は読み方で恥ずかしい思いをしなくて済みます。
私のECS学習方法
私自身がどのようにコンテナとコンテナオーケストレーション(ECS)と向き合い、どういった勉強したかをお話しました。
学び始めはそもそもコンテナの実態がイメージできないところから入ったので、以下の点を調べました。
- コンテナとはどういうもの？
- 仮想マシンと何が違うの？
- コンテナを使うとどういうメリデメがあるの？
- コンテナは私を幸せにしてくれるの？
その後、おおよそのコンテナはどういうものかイメージできたところでdockerとdocker-composeを反復実行しました。この作業目的はコンテナオーケストレーションを入れたとしてもトラブルシュートは避けられないと考えていたので基礎の勉強として3週間ほど起動しては停止する。時々コンテナを壊すといったことを繰り返しました。
そしてある程度コンテナ操作の肌感が掴めたと感じた時にECSとECRを触り始めました。
触った順番は以下のとおりです。
- Nginxにコンテンツを載せたコンテナイメージを作り、ECRへPush
- ECS on EC2(データプレーンを全EC2)でウェブ環境を作成
- データプレーンの強制終了、コンテナの強制終了、コンテナエージェントの通信制限を実施 (コンテナ環境はどうやったらサービス中断や影響を受けるのか知りたかった)
こういったところをやってきました。
ECSで躓いたポイントをご紹介
ECSを触っている中で躓いたことがあったのでご紹介しました。
ここまでが良い経験が出来たつまづきポイントのご紹介となります。
最後にコンテナに対しての想い
コンテナは起動停止だけでも出来るようになることで楽しくなります。
繰り返しコマンドを実行する中でトラブルシュート時の対応でよく見かけるdocker execという呪文の必要性を痛感しました。
GitHubのOSSリポジトリを見ると分かりますが、最近はdocker-composeで定義された形でアプリケーションが公開されることも少なくないと思います。その面を考慮すると、コンテナはAWSだけのものではなく一般的に利用ところまで来ているのでアプリケーション/インフラエンジニア関係なく触れないと今後は厳しいかと思いました。
ECS自体は少ないステップで設定が完了します、検証だけならばタスク/サービス/クラスターを覚えるだけで検証は出来ますし、サービスを提供している性格によって変わりますが本番環境であれば12 factor appを守るだけで運用出来るものもありますので触りやすいです。
AWSではKubernetesもECSといった選択肢が多い中でコンテナが利用できます。 今後はより盛り上がることが見えているコンテナ業界ですが、まだ触るのに遅くありませんので是非触って頂いて知見を共有して欲しいと思います。
Sli.doで回答していなかったご質問について
コンテナのOSは何を使うことが多いですか？軽量なやつ？
A.検証目的ではAmazonlinuxのコンテナイメージを利用することが多いですが、コンテナイメージのサイズを優先される方にはAlpineやBusyBoxが多いかと思います。
最後に(今回の勉強会を終えて)
リモートでの登壇は初めてだったので、不安と緊張を持って臨みました。 情勢面で外出が出来ないことで今回のようなリモート登壇を実施しましたが、少しさびしい気持ちになりました。 特に参加者の反応が見えない点はしょうがないと思います、きっと慣れだと思います。 お話が終わった後にSli.doを確認しました、質問してくれた方々には感謝しかありませんしTwitterで盛り上げて頂いてありがとうございました。 お話をしている最中はKeynoteのプレゼンモードだったので一切確認が出来ず、マイクに向かって独り言を話しているようで少し寂しかったですが反応があったのでトントンと思ってます。
とはいえ、札幌だけではなく社内の人間や道外の方も参加頂けるような勉強会の機会はそうそうないのでとても満足しました。 JAWS-UG Sapproの運営の皆さん、参加者の皆さん、本当にありがとうございました。
35
