【イベントレポート】JAWS-UG朝会 #66 #jawsug_asa #jawsug

いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！

今回は2025.02.04（火）に開催したJAWS-UG朝会 #66へ参加しましたので、アウトプットとしてイベントレポートを執筆しました。

初学者でもサクッと読めるように平易な表現で執筆しておりますので、お気軽に読んでいただければ幸いです。

誤字脱字、分かりづらい表現に関しては極力なくすように心がけていますが、リアルタイムで執筆しているため誤字脱字があるかもしれません。

イベントページ

目次

• セッション
  • セッション① AWS Networking RoadShow Gameday 2024 制覇に向けた学習のポイント
  • セッション② AWS re:Invent 2024 で考えるAWSマルチアカウント管理における“Simplexity” ～組織管理に関するアップデート～
• LT
  • LT① Redshiftのノード追加によるパフォーマンス改善で勘違いしていた話
  • LT② サーバー停止自動化にリトライ処理を加えてみた
  • LT③ AWS SimuLearnを使ったハンズオン学習
• まとめ

セッション

セッション① AWS Networking RoadShow Gameday 2024 制覇に向けた学習のポイント

参考サイト

• 自己紹介
  • NTTデータ所属のエンジニア
  • 金融・法人ネットワークの構築/運用を担当
  • 2024年にAWS Networking RoadShow Gamedayで優勝された
• AWS Networking RoadShow Gamedayとは
  • AWS主催のネットワークに特化したGameday
  • 2024年09月が日本初開催
  • Levelとして300～400（中～上級者レベル）
    • 対象者はAWSのネットワークの基本的な知識＋Linux知識
  • 1チームあたり3～5名に分けられる
  • AWS上でネットワークを作成・変更しクエストクリアしスコアを増やす
    • クエスト進行に応じてトラブルイベントが発生するため対処する必要がある
• 対策方法
  • 使ったことがないサービスを使ってみる
    • マネジメントコンソールやANS試験ガイドをチェックして触ったことがないサービスを触ってみる
    • 自ら考えた構成やシナリオを試す方法もあり
    • より効率的に進めるためにCloudFormationテンプレートが提供されているAWSハンズオン・ワークショップを活用してみる
  • リソース構成やパラメータ設定を理解する
    • どのようにリソースやパラメータが構成されているかを理解する
    • CloudFrontであればディストリビューションやポリシーも理解する
    • 具体的な要件が少ない場合はよくある設定＋AIを活用するのもアリ
  • 学習環境を代替サービスで再現する
    • 外部リソースが必要なネットワークサービス（Direct Connectなど）を触る場合は時間がかかる
    • 閉域網であればFIC（InterConnect社）を利用すれば代替可能
• まとめ
  • 使ったことがないサービスを試してみましょう
  • リソース構成やパラメータ設定を理解しましょう
  • 学習環境を代替サービスで再現しましょう

セッション② AWS re:Invent 2024 で考えるAWSマルチアカウント管理における“Simplexity” ～組織管理に関するアップデート～

参考サイト

• 自己紹介
  • NRIネットコム社のエンジニア野方
  • AWSマルチアカウント環境の組織管理・運用支援を行っている方
  • 今回の内容はNRIネットコム勉強回の内容をまとめた内容
• お話しすること
  • 2024re:Inventで語られたSimplicity×Complexityの深掘り
  • マルチアカウント構成での実装
• re:Inventおさらい
  • オッカムの剃刀：シンプルさを指向する
  • 意図しない複雑性によってイノベーションが遅くなることが問題
  • 複雑さへの対応
    • 6つの教訓
      • 進化する力
      • 複雑性の細分化
      • 組織形態
      • セルベースアーキテクチャ
      • 予測可能なシステム設計
      • 自動化
• 関連するサービス
  • 宣言型ポリシー（RCP）の登場
    • 従来のSCPはAPIレベルの承認ポリシー
    • RCPはコントロープレーンレベルの管理ポシリー
    • 中から外への制御と言う視点であればSCPがベター
  • コントロープレーンへ設定した内容はデータプレーンへ伝播する
    • （個人的考察）親から子へ伝えていく
  • Organizationのメンバーアカウントのルートアクセスを一元管理
    • ルートユーザの認証情報の管理が不要になる
• 組織管理における複雑性
  • 大きな問題として「イノベーションの遅延」がある
  • 利用者が負担するはずの複雑さが組織レベルに広がっていく
    • （個人的考察）複雑さが積み重なって手に負えなくなるイメージ
  • AWS Organizationを導入するだけで解決するわけではない
    • 6つの教訓を考慮してアカウント設計を行うことが重要
    • アーキテクチャ構成に合わせてアカウントを作る
    • 中央集権型 or 非中央集権型の運用のどちらを選ぶか
    • 組織単位（OU）を正しく設計することで影響分析が楽に
    • 解約済みアカウントを考慮した設計
• まとめ
  • 地味でも大事なAWSのハッシュタグを追っかけてみましょう

LT

LT① Redshiftのノード追加によるパフォーマンス改善で勘違いしていた話

• 自己紹介
  • 大和総研所属のエンジニアの方
  • 2023年のJrチャンピオンの方
• Amazon Redshiftとは
  • ざっくり言えば大容量データベースサーバ
  • 今回はプロビジョニングの話
  • リーダ・ノードそれぞれのマルチ構成がベター
• やったこと
  • シングル構成からマルチ構成へ変更（ノード追加）
    • メトリクス的に元のノードしか使われていない
    • 追加ノードがリーダーノードになってしまったのかといった勘違い
  • 事象についてAWSサポートへ問い合わせを行った
    • 2台に増やした場合コンピュートノードになる
    • 裏でリーダノードが構築される
    • ただし、ノード追加直後は適切にデータ分配されない
    • 必要に応じてVACUUMコマンドを実行
      • クエリ性能を向上させるメンテナンスコマンド
• まとめ
  • Redshiftについて
  • シングル構成はリーダーとコンピュートが混在している
  • ノード追加直後はデータ分散がされない可能性がある
  • 知っているとできるの間には大きな差がある

LT② サーバー停止自動化にリトライ処理を加えてみた

• 自己紹介
  • NTTテクノクロス所属の2年目の方
  • Webアプリ開発を担当されている
• 概要
  • コスト削減対策のためのEC2インスタンス停止自動化処理を実装
• 背景
  • インスタンス数増加に伴い、夜間休日の不要なインスタンス停止
  • CLIやマネコンぽちぽちは厳しいのでSystems ManagerとEventBridgeを利用
• やったこと
  • Systems Managerのランブック機能を用いて実装
  • Request Limit Exceededエラーが発生してしまった
    • API同時実行数の影響
• まとめ
  • Systems Managerを使えばインスタンス停止も楽に実装可能
  • SSMAUtomationランブックは便利

LT③ AWS SimuLearnを使ったハンズオン学習

参考サイト

• 自己紹介
  • 外資コンサルファームのクラウドエンジニアの方
  • 24新卒の方
  • 認定資格12冠の方
• SimuLearnとは
  • AWSのSkillBuilderのシミュレーション基盤
  • サブスクリプション契約が必要
  • ユーザからの依頼形式でアーキテクチャを実装
  • コンソールを触りながらリソース構築が可能
    • サンドボックス環境で構築するためリソース費用はかからない
• まとめ
  • 理論的な知識だけでなく、ハンズオンでAWS環境構築を行いたい方に刺さる
  • 実務シナリオに基づいてソリューション設計を行いたい方に刺さる

まとめ

AWS Networking RoadShow Gamedayでの取り組み方の話は実業務で活用できると思ったので、凄く参考になりました。また、AWSマルチアカウント環境の構築手法についてはキャッチアップしていきたいと思いました！！

今回得た知見を自身の中で言語化して伝えていくことが今後のアクションだと考えました。

最後まで記事を読んでいただきありがとうございました！