[レポート]これからコンテナを導入したい人必見！「JAWS-UG コンテナ支部 入門編 #6 コンテナの始め方」に参加してきた #jawsug_ct

はじめに

こんにちは、大前です。

初ブログ何書こうかなとか考えていたところ、「こんなイベントあるよ！」との情報を頂き、ブログ枠にて当イベントに参加してきましたのでレポートの方を書いていきます。

JAWS-UG コンテナ支部 入門編 #6 コンテナの始め方

タイトルやイベント説明からも分かる通り、本イベントは「コンテナ初心者向け」を謳っております。

私自身も、本などで基本的なコンテナ知識を頭の片隅に入れた程度のコンテナ初心者であるため、「これは自分にぴったりでは！」と内心ワクワクしながら参加してきました。

タイムテーブル

本ブログでは、下記２講演について取り上げます。

• AWS Expert Online これからはじめるコンテナワークロード - コンテナ化ベストプラクティス -
• 平成最後なのでEC2インフラからECS+Fargateに置き換えた話

AWS Expert Online これからはじめるコンテナワークロード - コンテナ化ベストプラクティス -

※発表資料については公開され次第掲載します

一つ目の講演は Amazon Web Services Japan の @toricles さんによる「AWS Expert Online これからはじめるコンテナワークロード - コンテナ化ベストプラクティス -」になります。

「これからはじめるコンテナワークロード」と題されている通り、

• DockerやFargateのチュートリアルやってみたはいいけど、どうやって本番環境にコンテナを導入していけば良いかわからない

な人を主なターゲットとした内容になります。

自分達のアプリケーションをコンテナ化して運用するまでの道筋が具体的なタスクに落とし込まれて説明されていて、初心者向けと言うこともあり細かい話は避けているようでしたが、コンテナ初心者の私にとっても非常に理解しやすく、学び・気付きの多い講演でした。

余談ですが、5/20-5/23にバルセロナで開催している KubeCon 会場からのリモート講演でした。かっこいい。

以下、印象に残った点をまとめていきます。

アジェンダ

1. コンテナにまつわる4つの誤解
2. なぜコンテナを使うのか
3. コンテナ導入から運用までのステップ
4. コンテナワークロード、次のステップ
5. まとめ

コンテナにまつわる誤解 = コンテナ化を阻む誤解

上記見出しはスピーカーである @toricles さんの言葉になります。とても的確な表現だと思い、引用させて頂きました。

「コンテナにまつわる４つの誤解」として以下が紹介されました。

1. 使うオーケストレーションは最初に決める必要がある
2. コンテナを使う＝マイクロサービス化
3. コンテナ化をすると開発・運用手法が大きく変わってしまう
4. コンテナ化は新規開発PJで実践した方が良い

誤解１：使うオーケストレーションは最初に決める必要がある

最初に使用する技術を決めるのではなく、「何を実現したいか、その為にどのツールが必要なのか」を検討する事が第一。

検討の結果コンテナが不要となるケースも。

誤解２：コンテナを使う＝マイクロサービス化

ユースケースの一つではあるが、少し飛躍しすぎ。必ずしもそうとは限らない。

誤解３：コンテナ化をすると開発・運用手法が大きく変わってしまう

ある観点で見れば事実だが、進め方次第で開発・運用手法を大きく変えずに進める事も可能。

誤解４：コンテナ化は新規開発PJで実践した方が良い

完全に正解とは言えない。むしろ既存のワークロードの方がやりやすい場合もある。

コンテナとオーケストレーションツールの関係と違い

コンテナの特性

1. 複数環境に渡って一貫して実行可能性がある
2. 可搬性の高さを支えるエコシステム
3. リソースの柔軟な割り当てと高速な起動と停止が可能

なぜオーケストレーションツールを使うのか？

コンテナは単一のノードに置けるライフサイクル管理

複数サーバにまたがってコンテナを配置したい時に出てくるのがオーケストレーションツール

コンテナ導入〜運用を３つのマイルストンに分ける

本講演のキモです。

コンテナ導入〜運用までのタスクを9つのステップに分け、さらに9つのステップを3つのマイルストンにグルーピングしてします。

各ステップ/マイルストンが非常に綺麗に分割されているため、本講演を聴講できなかった方も資料を一読する事をオススメします。

また、当然「最終的なゴール = コンテナ化の達成」でありますが、初めてコンテナ導入をする際は「既存システムの一部分のみをコンテナ化」する事をオススメしていました。理由は以下。

• コンテナ化を推進しているコンポーネント以外には影響がない為、現状のまま使う事ができる
• もしコンテナ化がうまくいかなくても、コンテナを消せば元に戻せる
• 新規のアプリケーションでコンテナを採用すると、「あれやりたいこれやりたい」と欲が出てしまう

「新規の〜」については、上記「コンテナにまつわる誤解」の４番目にも繋がっていますね。

では各マイルストンについて書いていきます。

マイルストン１

1. コンテナの特性とそれが解決する課題を知る
2. アプリケーションをコンテナ化する
3. 手動でデプロイする

マイルストン１の目的として「なるべく多くを変更せずに、コンテナでの動作を確認する」が挙げられています。

「既存の機能をコンテナで置き換える事」のみを考えることで、

コンテナ化してみる　→　デプロイ　→　うまくいかなかった部分を改修　→　デプロイ　→　...

のループが回しやすくなるそうです。

いきなりオーケストレータとか導入すると上記のループが必要以上に複雑になってしまうのは想像できますね。

また、コンテナ化する際のおすすめ手法として以下が述べられています。

• コンテナ化をした際の確認が楽なのでweb部分からコンテナ化をしていくのがオススメ（逆にバッチとかは確認に手間がかかる場合が多い）
• 既存のオフィシャルイメージやスクリプトなどを活用してdockerfileを作るとgood

一方で、この段階から考慮すべき主な点として以下が挙げられています。

• 1コンテナ = 1プロセス
• アプリケーションのステートレス化

マイルストン２

1. オーケストレータの特性とそれが解決する課題を知る
2. 仮想マシンの家畜化

マイルストン１で既存機能のコンテナ化が実現されたので、マイルストン２からは複数のコンテナを並べて走らせるという事を考えます。

• 複数ノードにまたがるコンテナ操作の特性を知ることで、コンテナイメージ作成のベストプラクティスに関する知識の裏付けが出来る
• 一つ一つのノードを意識するのではなく、大きな一つの仮想マシン群（リソースプール）としてコンテナを意識できるとgood

マイルストン３

1. チーム開発の為の開発環境準備
2. 運用を見据えたデザイン
3. 社内・チームの教育
4. システムとチームの成長を見据えたモダナイゼーションと最適化

晴れて既存機能のコンテナ化を達成し、いよいよ本番環境への反映をしていくぞという段階として、マイルストン３が始まります。

マイルストン３の目標として、以下が述べられています。

• 今まで出来ていた作業がコンテナ化しても出来ることを担保する
• コンテナ導入のメリットを最大化し、ノウハウを蓄積する

「せっかくコンテナ化頑張ったのに前より作業がめんどくさくなってない？」などは起きないようにしましょう、という事だと思います。そもそも何かしらの課題を解決するためにコンテナ化を進めたのに、結果課題が増えたら元も子もないですからね。。

ここで私が個人的に印象に残ったのは「ドキュメンテーション」という単語が複数回に渡って出てくる事です。

チームでPJを回した事のある方なら誰しも経験したことがあるであろう、「属人化」による悪影響。あくまで「コンテナ化を進める中で気をつけること」として述べられていますが、コンテナ化に限った話ではないのは誰もが実感しているかと思います。

• システムを理解している人が少ない状態は非常に脆弱
• 自動化を進めると同時に、何かあった時用の手作業のマニュアルも準備する
• ここまでのステップについての意思決定の意図も共有する事で、他メンバーも改善のイテレーションが回せるようになる

まとめ

コンテナ化進めたいはいいものの、どうやって進めていけば良いのだろうか、、、な方にとっては非常に参考になる講演で、私自身もコンテナ初心者として学ぶことが多かったです。

特にマイルストン３のドキュメンテーションの重要性を説く部分では、非常に納得する点が多く、過去の出来事を思い出しながらウンウン頷いていました。

現場の環境は多種多様ですので、全てのケースに今回のワークロードがうまく当てはまるとは限らないかもしれませんが、これからコンテナ化をしようと考えている方は、一度このワークロードを参考にしてみるのも良いと思います。

平成最後なのでEC2インフラからECS+Fargateに置き換えた話

二つ目の講演は 株式会社エウレカ の Masashi Yamamoto さんによる「平成最後なのでEC2インフラからECS+Fargateに置き換えた話」になります。

一つ目の講演が「こうやってコンテナ化進めると良いよ」といった内容だったのに対して、こちらは「実際にコンテナ化やってみた」講演になります。

前の講演でコンテナ化を進めるための基盤となる考え方を学んだ後に、実例のお話を聞けるのはとても良かったです。

概要としては、タイトルの通り「EC2からECS+Fargateに移行した話」です。

コンテナ導入についての What-Why-How が実際に行った取り組みに沿って紹介されており、コンテナ導入を始める際には非常に参考になりそうだなという印象でした。

チーム紹介で各メンバーをazに例えていたのはめちゃくちゃ面白かったです。（どっかで使いたい）

上に同じく、印象に残った点を自分なりにまとめてみます。

アジェンダ

1. 背景〜技術選定
2. コンテナ構成・設計指針
3. デプロイ、スケーリング、監視のお話
4. まとめ

そもそもなんでコンテナ化したの？

コンテナ化のきっかけは「インフラ反映がつらかった」との事でした。

具体的には、ビルド〜デプロイで行うタスクが多く、手作業もあり時間的コストが大きかったとの事でした。

また、コンテナの利点として以下が挙げられています。

• プロセス単位で構築可能
  • 使用するミドルウェア同士での依存性の競合などを気にしないで済む。
    • 修正・追加による影響を狭く出来る。
  • 機能追加・修正は役割別にコンテナ単位で修正/追加が可能
    • 修正・追加の単位を小さく出来る。
• 起動・廃棄が高速
  • スケールアウトの速度向上
  • immutable infrastructureの実践に適している
  • アプリケーションをデプロイするような感覚でインフラデプロイができる。
• ポータビリティ
• etc...

EKS or ECS on EC2 or ECS on Fargate どれ使う？

結果として採用したのは Fargate。

主な理由としては以下。

• 起動速度や価格面では EC2 on ECS（+SpootFleet）が優位
• チームメンバーのリソースに限りがある為、なるべく運用/管理コストを減らす事を優先した結果、Fargateに

kubernetesには後々移行したいとのこと。

機能や値段、性能だけでなく、実際の運用コストまで比較して使うサービスを決めた、という点で一つ目の講演のマイルストン３の話に近しいものを感じました。

「コンテナ導入によるメリットを最大限享受する」という点で見たとき、運用コストは非常に大事な要素になるのだと思います。

設計・構成どうした？

コンテナ化のメリットを出来るだけ享受しやすい構成を考えた結果、各ベストプラクティスを実践することに。

• Twelve factorApp
• Docker Best Practice

参考

Twelve factorApp

Docker Best Practice

• １コンテナ＝１プロセスを意識して各コンテナの責務を小さくしたため、修正などは楽になった
• コンテナ間の共有ボリュームを使って監視・分析をしている
• アプリ側で複合や環境変数を意識しないような作り

基本的には各種ベストプラクティスを基に設計・構築を行ったという内容で、「Web部分からコンテナ化を進めた」など、語り手は違えど一つ目の講演と同様の考え方が所々にあったのが印象的でした。ベストプラクティス、大事。

まとめ

一つ目の講演を聞いた後に本講演で具体的な導入事例を聞くことで、コンテナ導入までの道筋について理解をより一層深めてくれた講演だと感じました。

また、本レポートでは紹介できておりませんが、

• デプロイパイプライン
• スケーラビリティ
• 監視・ロギング
• dockerImageの軽量化
• ログ転送をコンテナ債務から取り外す

といった内容について具体的にどういったサービスを採用したのかが紹介されておりますので、気になった方は是非資料を一読していただくと良いかもしれません。

今後

コンテナ初心者としては非常に学びの多いイベントで、満足感もすごく高かったですが、実際手を動かさないと身につかない部分ばかりだと思うので、コンテナ関連の「やってみた」系のブログも頑張って書いていこうと思います。