3/14 JAWS-UG朝会 #31 に参加しました。久々に参加レポートを書きます。
目次
- 目次
- イベントページ
- セッション内容
- 所見
- 最後に
イベントページ
セッション内容
セッション① Amazon Linux 2022をさわってみた 株式会社サーバーワークス 小倉大さん
Amazon Linux 2022とは
- 現時点ではプレビュー版。
- Amazon Linux 2 の後継バージョンOS(2023年6月30日で長期サポートが切れる)
- 5年の長期サポート
- 最初の2年はアクティブな開発フェーズ。後の3年はメンテナンスフェーズ。
Amazon Linux 2との違い
- SSM Agentがデフォルトで入っていない
- 手動インストールが必要
- EC2作成時にインターネットへ疎通できるようにする必要がある。
- S3へSSM Agentのパッケージを取りに行く。
- セッションマネージャーでログインする時にSystems Managerへアクセスする。
- SE Linux がデフォルトで有効
- SSH接続がデフォルトでRSA無効
新機能を確認するときのやり方
- とりあえず手順をあまり見ないでマネコンを触り、詰まったら調べて対応する。
- これの繰り返しをして、詰まったところを調べた方が覚えやすい。
資料
www.slideshare.net
セッション② インプレースデプロイからBlue/Greenデプロイへの変更をゴリ押しで進めた話 株式会社サーバーワークス 古川敏光さん
既存環境
- 複数の環境がFargate上で稼働している。
- Internal ALBによるサービス間通信。
- ECSはローリングアップデート
- EC2上にJenkinsを構築
BGデプロイ実装方法
懸念点
- サービス間のアクセスをどうするか?
- ALBの後にNginxを配置してURLでリバースプロキシ先を切り替える。
- Fargate上にNginxを構築して、各ECSコンテナに自動でAレコード登録をする。
ゴリ押しポイント
- 既存テンプレートを使いたいので、ServerlessFrameworkを使う。
- ターゲットグループ1つに対して、関連付けられるリスナールールは1つのみ。
- ターゲットグループとリスナールールの関連付けを自ら行う必要がある。
まとめ
- BGデプロイ手法に正解はない。
- 実装コストやダウンタイム許容時間など、要件に沿ってデプロイ手法を決める。
- Codeシリーズの方がCI/CDの実装コストは小さいが、Jenkinsの方が細かいジョブを設定できる。
資料
LT① AssumePolicyの意外なハマりどころ 崎原晴香さん
今回実現したいこと
- とあるAssumeRoleの権限移譲先として、あるグループに属しているIAMユーザ全員を指定したいケースを考える。
- しかし、IAMユーザグループをAssumePolicyのプリンシパルに指定することはできない。
解決策
- TerraformのDataSourceを利用
資料
LT② DirectConnectGatewayの罠!? 株式会社ターン・アンド・フロンティア 坂下朱紀さん
DirectConnectGatewayとは
構成変更で分かったこと
- DirectConnectを冗長化してActive-Active構成にすると、戻りの通信が異なる経路になってしまう。
- VGWは複数のDXGWに紐づけられない。
- DirectConnectGatewayを使わずDirectConnectを冗長化した。
資料
www.slideshare.net
LT③ 漏洩しても大丈夫なクレデンシャル運用ができないか考えてみた 株式会社ゲームエイト 岩佐海彦さん
やらかし防衛策を並べてみたらIP制限したくなった
- リーク先のリモートからではなく端末上で叩かれるのは防げない。
可変IP、複数IPでも使える基盤を考える
- 未許可のIPからでも許可申請を受け付ける必要がある。
- 踏み台IAMユーザを作る
- 踏み台ユーザはMFA必須。かつキャッシュしないようにする。
- 複数IPでも利用できるようにするには
IAMの権限を書き換える権限の注意
- ポリシのJSONを書き換えることになるため、IPリストだけ書き換える権限は作成不可
- 脆弱性を持たせるところだった。
- 編集権限はパーミッションバウンダリーのJSONとし、エスカレーションリスクなく権限を絞ることができた。
資料
LT④ AZ間レイテンシを比較してみた 積田 優生さん
前提知識
- リージョン
- アベイラビリティゾーンを束ねた設計
- アベイラビリティゾーン(AZ)
- 複数のデータセンタによって構成された耐障害性を意識した設計を採用
- どのリージョンも2つ以上のAZで構成されている。
- AZは1つ以上のDCから構成されている。
- 複数のデータセンタによって構成された耐障害性を意識した設計を採用
- AZ名とAZ IDについて
レイテンシ(ラウンドトリップ)測定概要
- 東京リージョンと大阪リージョンのAZ間レイテンシを測定
- 各サブネットにEC2(m5.large)を1台ずつ作成
測定結果
- 単一のAZのみを利用する場合、同一AZ内でレイテンシの差はどのAZでもほとんどない。
- 大阪リージョンのAZ間レイテンシが想定以上に低かった。
- AZ間でのレイテンシ要件が厳しい場合は、大阪リージョンを利用するのも1つのオプション
資料
所見
リージョンとアベイラビリティゾーンについては意識しないと忘れることが多そうなので、今回の朝会で見直そうと思いました。
認証認可の管理方法も環境によってさまざまな実現方法があるんだと思い、奥の深さを感じることができました。
サービスや実装方法の深掘り、とりあえず触ってみることもあまりできていないので、もっと研究してみたくなりました。
最後に
2022年一発目の記事でした。年が明けてから勉強会に参加していたものの、ブログレポートは何か書く気が起きず…それ以外のネタも書けず…書こうと思っても書けませんでした。
最近勉強会に参加してても散漫になっていると思い、今日はブログ書く前提で参加しました。その意識があるだけで、発表の聞く集中力が全然違いました。今後もなるべくアウトプット前提で勉強会に参加していこうと思います。
ブログ休んでたのはちょっと思うところがあってなので、その辺は書けたら書こうと思います。