血と汗となみだを流す

クラウドエンジニアになるための修業の場

# JAWS-UG コンテナ支部 入門編 #6 コンテナの始め方に参加しました!(前編)

前編とは

  • 内容が濃すぎたため、1回で書けませんでした・・・
  • 前編は@toriclsさんと@marnieさんのセッションについてアウトプットしたいと思います。
  • ハンズオンはまだちゃんと理解できていないので、理解した上で後編を書きたいと思います。

後編リンク

概要

  • JAWS-UG コンテナ支部 #6にブログ枠で参加させていただいたのでそのアウトプットです
  • 最初のセッションはJAWS-UG全7支部が参加して、目黒で流す@toriclsさんの動画を、他の支部へ中継するという形式でした(@toriclsさん自身はバルセロナにいたらしい)
  • @toriclsさんの動画は隅から隅まで素晴らしい内容でした
  • 全部書き出すより、動画が公開されたらそちらを見てもらうほうが良いと思うので、動画の中で特に自分に刺さったものを書いています
  • @marnieさんのLTの内容は自分の業務にかなり似ている構成だったのでいろいろお聞きしたかったけど、できなかったのが心残り・・・
  • ハンズオン資料はGithubに公開されており、AWSアカウントがあれば誰でも実施することができます。ぜひ手を動かしてみることをお勧めします

書いてる人

  • 事業会社のインフラ系の人
  • サービスでAWSを利用している
  • サービスの一部をコンテナ化しているが、まだ十分な知見はない
  • 社内でのコンテナ導入の温度はまだ低いため、どのようなケースでコンテナが役に立つのか模索中

資料のリンク

ハッシュタグ

#awsxon
#jawsug
#jawsug_ct

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

ゴール

- ローカルでdocker runから始まって、本番環境で運用するまでのフローを学ぶ
- コンテナを本番運用していくためのフローににマイルストンを置いてタスクをイメージできるようになる

コンテナ化について

- 「コンテナ化すること」を目的とせず、何を成し遂げたいのか、どんな問題を解決したいのかを考える
- そもそも本当にコンテナが必要か?
- マイクロサービス化はコンテナのユースケースの一つ
  • 「何でもコンテナに載せてしまえば良い」という考え方をせず、要件にあったサービスやツールを選択して、「それが何故良いのか?」という理由をしっかり理解した上で、現場に説明できる力がないとだめだなと思いました。
  • コンテナ化/マイクロサービス化、その他手法についても最適なソリューションを選択できるように学んでいかねば・・・!

コンテナの導入から運用まで

- コンテナ導入は既存ワークフローへ適用する方がやりやすい
- 新規プロジェクトだとあれこれ欲が出てしまう
- まず既存のワークフローを変えずにコンテナ化をしてみる
- トライアンドエラーを繰り返し、改善のイテレーションを回すことが近道
- うまくいかない場合はコンテナを消せば元通りという状況を維持する
- これまで使ったことがない技術の導入には成功までの道筋が必要
  - 組織や文化的な課題も入る場合がある
- ゴールまでのマイルストンを適切に配置する
  • てっきり「新規開発でパイプラインをしっかりつくって導入!」が良いと思ってました
  • 既存のリファクタリング的な感じで置き換えていくのは良いなと思いましたが、モノリス化してしまっている箇所にどうメスを入れるかは課題です
  • コンテナ化に関わらず、「文化」という面での課題も取り込んでいかないと全体的な最適化は難しいと感じました

コンテナ導入から運用までのステップ

- 1st Milestone
  - コンテナの特性とそれらが解決する課題を知る
  - コンテナ化
  - 手動でデプロイ
- 2nd Milestone
  - オーケストレータの特性と解決する課題を知る
  - 仮想マシンの家畜化
- 3rd Milestone
  - チーム開発のための開発環境構築、自動化、CI/CD
  - 運用を見据えたデザイン
- 社内・チーム教育
- システムとチームの成長を見据えたモダナイゼーションと最適化
  • 3rd Milestoneからやっていくつもりだったけど、利用者側からしたら「何か環境変わってよくわからないけど使う」みたいな意識になってしまいそう
  • 「与えられた環境を使う」ではなく、段階的に広めていく重要性を感じた
  • こちらを聞いて、実際に1st Milestoneをやってみようと思いました
  • 実際に社内でも「まずは手動で雑にコンテナ化してみて、どう使うのが良いのかを体感する」というのを始めてみました。

コンテナワークロードまとめ

- ゴールと道筋を明確にする
- はじめてのコンテナワークロードには既存アプリケーションがお勧め
- コンテナ化から本番導入まで、全てにおいてイテレーションを回す
- コンテナ化にあたっての作業量、チームメンバーのオンボーディングの考慮
  • 以下をしっかり意識しないといけないと思いました
    • まずコンテナ云々の前に、何をしたいのか
    • 現状とゴールとの距離はどれくらいあるのか
    • 現状の文化に適した形のワークフロー
    • 場合によっては文化を変えていく
    • コンテナ化を「与えられたもの」では無く「自分たちで考えた自分たちに取って最適なソリューション」となるような自発的なアクションを促していく

twitterに投稿されたQA

- 異なるインスタンスタイプのノードを用意するのはなぜ?
  - あるインスタンスが起動しなくなる可能性がゼロではない
  - ミックスしておくことで確実にキャパシティを確保しやすい
  - コンテナとか関係なく、それなりの規模のクラスタを運用するときはやっておくべき
  • t3/m5は人気で、Availability Zoneによっては起動しないことが多く、スパイクした時のスケールアウトのリスクヘッジとして色んなインスタンスタイプを用意しておいたほうが良さそうと感じた
  • ただ、アプリケーションの特性によってインスタンスタイプを用意(r系やc系)しておくことが多いので、どのように使い分けるかはアプリケーションの特性を考えないと行けないと思った

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

発表者

  • Masashi Yamamotoさん(@marnie)
  • SRE at eureka

発表内容について思ったこと

  • 構成が弊社のものとかなり近かったので、弊社との違いなどについて書きます。
- AZと同じ人数しかいない
- Aが疲弊している
  • ap-northeast-1bが過去に居たのかな・・・?!
  • AZごとの疲弊度は都度監視しないといけないな・・・
- packer + ansibleで作成したGolden Imageをterraformで展開
  • 同じやり方だ!!!
  • ただ弊社がやっているのは、コードは別途Githubからpullしてくるパターン
- コンテナ化のきっかけ
  - 本番反映までのコスト
  - 割と肥大化してきたplaybook
  • 環境変数の反映などはコストが発生していたが、現在はSecret Managerから別途取得する方法に変更してコストを減らした
  • コードの反映は別途行っているのと、AWS側の変更が発生することがそんなに無いため、それほどコストでは無い
  • playbookのメンテナンスは確かにコストになるかも(ansibleのバージョンアップなど)
- ECS + Fargateを選択した理由
  - 起動速度や単純な価格面ではEC2 on ECS(+SpotFleet)の方が有利
  - チームの管掌領域が広いのでなるべく運用/管理するコストを減らしたい
  - 今の時点ではEKSよりECSの方が運用・AWS内の別コンポーネントとの連携が充実してきている
    - Dataplaneのマネージドがきて、いろいろ枯れてきたら・・・!
  • たしかに同じ判断でECS + Fargeteを検討していました
  • 弊社としてはログやメトリクス管理を一元化して運用コストや学習コストを下げたいと思ってDataDogを選択した
  • しかし、DataDog LogsがまだFargateからのログ転送に対応してないので、DataDogが対応するまでデータプレーンはEC2を選択しました
    • CloudWatch Logsからの転送はまた別途Lambdaとか必要なのでやめました
  • EKSも面白そうですが、まだECSの方がいろいろ楽な面が多いと思います。今はECSでコンテナオーケストレーションの知見を貯めよう
- docker imageの軽量化
  - アプリケーションコンテナに不要なものが含まれている
  • 「コンテナに入れなくて良いもの」をちゃんと切り出していかないと、ECRからのpullで課金が死ぬ
  • サービスを起動しっぱなしならまだ良いけど、スケールしたり単発のタスク実行の場合はdocker imageの容量はできるだけ少なくしていきたい
- ログ転送をコンテナの責務から取り外す
  • Kinesis Firehoseで転送できることを知りました
    • そもそもKinesisシリーズをよく知らず・・・
    • Associate認定で、使い所はざっくり知りましたが、具体的なユースケースをちゃんと知らないと選択肢が増えないな
  • サイドカーだけで全部完結できるようになると幸せ
- コンテナ=銀の弾丸ではない
  • コンテナはやりたいことを実現するための一つの手段、として考えなければ行けないなと思いました。
  • (コンテナ使ってみたいという欲望だけではダメ)

感想

  • 内容がたっぷり詰まった有意義な時間でした!
  • 特にtoriclsさんの動画は、これからコンテナを導入する人は必ず見たほうが良いと思います。(弊社内でも動画を共有しました)

次回

  • ハンズオンをじっくりやり、何をやっているかをしっかり理解した上でアウトプットしたいと思います。
プライバシーポリシー