[イベントレポート] JAWS-UGコンテナ支部 入門編 #7 初心者大歓迎LT大会 #jawsug_ct
2022/8/9 に行われた JAWS-UGコンテナ支部 入門編 #7 初心者大歓迎LT大会 に参加したので、発表を聞いての学びと感想をイベントレポートとして記事にしました。
EKS AnywhereとIAM Roles Anywhereを組み合わせてみた
登壇者：株式会社ビッグツリーテクノロジー&コンサルティング 竹中太基 さん (@tknk_tknk)
登壇内容
- EKS Anywhere とは
- EKS と同じ Kubernetes 環境をオンプレミスに構築できる
- eksctl コマンドで Cluster API によって構築する
- ドキュメント通りにコマンドを叩けば立ち上がるので超簡単
- IAM Rorles Anywhere とは
- AWS 外部のリソースに対して IAM 権限を付与できる
- やってみての感想
- S3 などの認可のために IAM ユーザーを作らなくてよいのがよかった
- 認証用の秘密鍵はどこに持たせるべきかよい答えが見つからなかった
- aws_signing_helper は SDK に同様の機能が欲しい
以下のリポジトリでサンプルコードが公開されています。
感想
IAM Roles Anywhere が発表されたとき、自分には縁がなさそうだなーと思って完全にスルーしていたのですが、こちらの LT を聞いてちょっと興味がわきました。
5分の尺でしたがもっと深掘りした内容も聞いてみたい！と思うセッションでした。
こちらも要チェックですね。
ECS Fargate + Mackerel における監視費用を削減するまでの話
登壇者：株式会社ヌーラボ 中野雅之 さん （@maaaato）
登壇内容
- Backlog の Git の機能を開発するチーム
- ECS Fargate の監視に Makerel と CloudWatch Container Insights を使っている
- Mackerel の費用が上がったことでホストメトリック数の超過に気づいた
- Mackerel のホストの種類
- スタンダードホスト
- マイクロホスト
- 今回はこっちの話
- マイクロホストメトリック数とは
- ホストメトリック: サーバーに紐づくメトリック
- マイクロホストメトリック数は上限値が 30
- 30メトリック毎に1マイクロホスト分の費用が発生する
- 超過したホストメトリック数に対しての判断
- アプリケーション以外のメトリクスは必要がないと判断した
- 他のメトリクスが安定していることがわかったため
- アプリケーション以外のメトリクスは必要がないと判断した
- 結果
- ホストメトリック数が30を切った
- Mackerel の費用も下がった😄🎉
- まとめ
- ホストメトリック数の扱いを把握できていなかった
- 今回は必要がないと判断したが、必要なメトリクスであれば無理に止める必要はない
感想
チームで毎朝メトリクスをチェックした結果必要なメトリックとそうでないメトリックの判断ができたエピソードが印象的でした。
継続的な計測によってよい判断ができて費用削減に繋げられるのとても素敵ですね。
Amazon ECS on EC2 で Auto Scaling やってみる！
登壇者：アルカセット・コンサルティング株式会社 山本政治 さん （@gringriffin）
登壇内容
- ECS on EC2 の2種類のスケーリング
- タスク
- インスタンス
- 制御の仕組み
- インスタンスの Auto Scaling
- キャパシティプロバイダが制御する
- DesiredCapasity を更新
- 判断は CapacityProviderReservation で行う
- CPR = 必要なインスタンス数 (M) / 現在のインスタンス数 (N) * 100
- M: タスクの配置に必要なインスタンス数
- プロビジョニング状態のタスクも含む
- M: タスクの配置に必要なインスタンス数
- Nの増減 = Auto Scaling
- キャパシティプロバイダは CPR の値をターゲット値に近づけようと頑張る＝スケーリングの制御
- インスタンスの Auto Scaling
感想
キャパシティプロバイダの制御についてのスライドがとてもわかりやすかったです！
このあたりをちゃんと理解していなかったことに今日気づけたのでとてもありがたかったです。
実況ツイートであがっていたこちらのブログも要チェックです↓
ECS Fargate でも SystemCall を検査したい
登壇者：GOODWITH LLC., 天地知也 さん （@tomoyamachi）
登壇内容
- 直前でタイトルを変更した：「ECS Fargate でも 無料で証跡管理したい」
- 対象
- コンテナランテイムセキュリティに興味がある人
- コンテナセキュリティの予算が取れなかった人
- Fargate の問題点: コンテナに侵入された場合、後で解析ができない
- Fargate の場合 VM 領域がユーザー管理ではく AWS の領域なので snapshot を利用できない
- 利用中のコンテナが終了すれば調査できなくなる
- 想定しない動作があった際でも検知・証跡管理したい
- 不審なポートでの通信
- 許可してないファイルの読み書き
- 証跡管理の導入方法
- 商用サービスを利用する
- 年間300万くらいかかる
- 証跡管理以外の機能も利用可能
- OSS で頑張る
- 無料
- 理解が必要
- トラブルシュートする技術が必要
- 商用サービスを利用する
- 今回利用するOSS
-
Falco
- コンテナランタイムセキュリティのデファクトスタンダード
- pdig
- ptrace ベースで Falco を動作させるためのライブラリ
- 登壇直前に Public Archived になってしまった・・・
-
Falco
- この方法の利点
- Fargate 環境でも無料で証跡管理が可能
- Falco を利用することでルール違反したSystemCallのみ出力できる
- 正常動作のときにログが大量出力されずに済む
- この方法の欠点
- ptrace を利用するため処理が遅くなる
- メンテナンスに不安が残る
- pdig の Archive
- libs が最新版だと動作しない
- 動作保証ができない
感想
セキュリティ面だけ見ても ECS on EC2 / Fargate どちらの場合でもメリデメがあり方針をもって決定することが大事だというのが印象的でした。
OSS の方法を選択した場合の利点・欠点がわかりやすくまとめられていて勉強になりました。
最後に、コンテナイメージ検査ツールの dockle でメンテナを募集しているそうです。
AWS Hands-on for BeginnersのECSハンズオンをAWS CLIでやってみる
登壇者：アイレット株式会社 鈴木健斗 さん （@k_suzuki_pnx）
登壇内容
- 背景
- 業務でコンテナは触らない
- コンテナ歴はチュートリアル程度
- コンテナに興味あるけど何がわからないのかわからない
- →とりあえず初心者向けハンズオンをやってみよう
-
AWS Hands-on for Beginners
- 現在 22 のハンズオンがある
- ECS ハンズオンは2022年6月に公開された
- AWSコンソールで ECS ハンズオンをやってみた結果
- コンテナできる・・・！の全能感に満たされた
- コンソールをぽちぽちして気づいたらハンズオンが終わっていた
- 裏で CloudFormation スタックが作成されている
- 実際はなんの API を実行してどのような設定値のリソースが作成されたか不明
- → CLI でやってみることに
- CLI は CloudShell から実行した
- 最初から AWS CLI がインストールされていて環境構築が不要
- ECS のサービスがハンズオンをやっていて一番わからなかった
- マネコンからだとロググループが自動で作成されるがCLI経由では作成されない
- CLI は CloudShell から実行した
- 学び
- CLI だとなんのサービスがどのような設定値で作成されているかがよくわかる
- マネコンだと裏でよしなにやってくれるので把握できない
- CLI だとなんのサービスがどのような設定値で作成されているかがよくわかる
- 学んでいく中でそもそも Dokcer をそこまで理解してないことがわかった
- 何をわかっていないかがわかった！
感想
CLIを触ってみて初めてマネジメントコンソールでよしなに作ってくれているリソースの正体を知るのあるある〜！！と思いながら聞いていました。
（余談ですが私の場合は CloudFormation を触って初めて IAM のインスタンスプロファイルの存在を知りました。）
マネコンで何をやっているかわからないとき CLI を触ってみるという発想が今までなかったのですが、よい方法だなと思いました。
SAM × Dockerでサーバーレス開発が超捗った話
登壇者：チームラボ株式会社 ゆっきー さん （@Yu_yukk_Y）
登壇内容
- 開発中のアプリ
- Nexus Square
- 出身大学の学生館の情報格差をなくすアプリ
- 利用者の上限が低い（最大3000人程度）、開発メンバーが少ない、費用面からサーバーレスアーキテクチャを採用
- 初期の開発環境
- とりあえず GitHub に push
- テストが走る
- Lambda のコードのみ更新
- 問題点
- 動作確認は単体テストだより
- ローカルで動作確認できない
- デプロイ時にコンテナの良さを活かしきれていない
- Lambda 以外は手動更新
- Blue/Green デプロイと相性が悪い
- Lambda 以外は手動更新
- SAM を導入することに
- AWS SAM とは？
- OSS
- IAM ポリシーも管理・作成できる
- API のローカル実行も可能
- コンテナのビルド・デプロイも自動化可能
- 改善できたポイント
- ローカルで API が実行できるようになった
- ローカルでは Docker Compose で別途 DynamoDB local のコンテナを立てておいた
- ローカルとデプロイ先で差分のない実行環境ができた
- Lambda のコード以外も一括更新できるようになった
- IAM ポリシーなど
- 現状
- Blue/Green デプロイに Lambda のエイリアスが使えない
- 現状の対策として、バージョンごとに Lambda, API gateway を作成する / Cognito, DB は SAM で開発しない
- まとめ
- SAM の導入で開発環境が大きく改善した
- 運用していく中で改善を続けていきたい
感想
プロダクトの初期の開発環境からの問題点、そこからの改善に至るまでの流れを知れてとてもおもしろいセッションでした。
私自身は SAM を使ったことがないのですが、メリデメを知れたのも勉強になりました。
これから運用とのことなので、その先でどのように改善したかというお話も楽しみです！
ECS Exec を使った ECS のトラブルシューティング
登壇者：アイレット株式会社 堂原竜希 さん （@ryu_dohara）
登壇内容
- クラウドのコンテナはローカル検証が難しい
- クラウドコンテナならではの要件
- ECS 間通信管理に AppMesh しよう
- ECS 外のサービスへのサクセス
- AWS API を叩く
- クラウドならではの設定
- セキュリティグループ
- IAM ロール / ポリシー
- VPC エンドポイント
- エラーが発生したときにコンテナの外からでは原因追求が難しい
- データベースにアクセスできないのはなぜ？
- APIを叩いてエラーになるのはなぜ？
- ECS でも docker exec と同様のことができる！
- コマンドの実行
- シェルへのアクセス
- 便利な点
- コンテナへのツールのインストール不要
- SG でポートを解放する必要がない
- SSM のセッションマネージャーを利用しているため
- ログを残せる（設定が必要）
- CloudWatch Logs
- Cloud Trail
- IAMベースで権限管理できる
- SSM のセッションマネージャーが使われている
- タスクロールで SSM アクセス権限を付与する必要がある
- プライベートサブネットに配置している場合は VPC エンドポイントが必要
- 有効化するためには
- タスクロールに必要な権限を付与
- タスク定義において initProcessEnabled を有効化（必須ではないが推奨）
- ECS サービスにおいて ECS Exec を有効化
- （プライベートサブネットであれば）VPC エンドポイント作成
- 実行アカウントに IAM ポリシー付与
- 初めて設定するときはハマりがち
- → Amazon ECS Exec Checkerがある
- ECS Exec を利用できる環境が整っているかチェックしてくれる
- まとめ
- トラブルチェッカーのお供として Amazon ECS Exec を利用してみては？
感想
ECS Exec、存在は知っていたのですが使ったことがなかったので利用されているお話が聞けておもしろかったです。
IAM ポリシーの付与や VPC エンドポイントの作成など、聞いているだけで確かにハマりどころが多そうだなと思ったので、Amazon ECS Exec Checker はぜひ使いたいですね！
ECS Exec についてはこちらもチェックしてみるとよさそうです↓
イベント全体の感想
今回目黒のAWSのオフィスで現地参加したのですが、オフラインの勉強会はその場の雰囲気が楽しめたり周りの人と技術の話ができたりしてやっぱりとても楽しかったです。そしてなんかモチベーションが上がる。
初めて知るツールや触ったことのないサービスのお話が聞けたのもよかったです。
運営の皆様、登壇者の皆様ありがとうございました！
次回も物理開催を期待して楽しみにしています！！
Discussion