地球最速レポです。
Reject Day 2023とは？
AWSのユーザーコミュニティJAWS-UGやAWS Startup Communityの仲間と一緒に、AWS Dev Dayで登壇応募したものの惜しくも当選できなかった方を全員救済するLT会！を開催しました。
ちなみに会場はKDDIおよびKDDIアジャイル開発センターにて普段利用している虎ノ門ヒルズビジネスタワーにて用意しました。（休日なので設備借用の準備が実はかなり大変でした…ｗ）
本記事では各セッションの内容抜粋＆感想を雑にまとめます。
第1部
オンプレシステムのクラウドリフトにおいてBLEAを利用してセキュリティのベースラインを確保した話 / 川村 吏さん
- BLEAはAWSが提供しているセキュリティ初期設定のテンプレート。CDKで提供
- AWS CDKを使えばCloudFormationのように細かいコードを自分で書かなくて良くなる
- 環境に合わせていくつか個別にテンプレートのカスタマイズも実施した
- BLEAリソースの命名修正はかなり手間がかかるのでオススメしない
- BLEAで設計がかなり楽になり、CDKでのお手本構成を学習できた
AthenaとCloudWatchで始める低コストなSLOエラーバジェット監視 / 岩本 隆史さん
- SREの基本用語としてSLO、エラーバジェット、バーンレートの解説から
- バーンレートの監視にSaaSツール等を使うと見積もりがめちゃ高かった！（月額１０万円）
- CloudWatchとAthenaを使って自分たちで工夫してみた。AthenaでALBログを集計
- 2週間弱で実装！SaaSよりもかなり安くできた（月額15.7ドル）。気軽にやるならかなり良いプラクティスになった
EC2からのECS移行においてIaCとCDをどう変えたか / 山原 崇史さん
- Elastic BeanstalkからECSへ移行。世の中のベスプラを取り込み、開発チームがCDから遠ざからないように工夫した
- コンテナ化の前に環境差異をすべて環境変数で吸収した
- コンテナイメージはECRで各環境へレプリケーション。（そうでない場合はCI/CD専用アカウントを用意する手もあり）
- CDツールはCodePipelineを選定。Beanstalkとの並行稼働や承認運用でのメリットをとった
- ECSデプロイにecspressoを採用することでデプロイ後のIaC差分回避や開発チームへの権限委譲を狙った
- 開発チームのメンタルモデルを考え（直感的になるように）、デプロイ開始トリガーをmainブランチへのマージとした
様々なプラクティスが凝縮された神セッションでした！
モノリスウェブアプリケーションのクラウド最適化について / 吉岡 隆行さん
- My RedmineというSaaSサービスを提供。コンテナでステートレスに構築
- 手作業でやっていた作業を自動化した
- バッチ処理用のコンテナを並列実行。LambdaとFargateを使い分け（実行時間と並列処理で選定）
- StepFunctionsでワークフロー作成。それまではLambda on Lmbdaで頑張っていた
第2部
気がついたらSagaパターンになっていた！少人数で運用するサーバレスバックエンド / 三浦 一樹さん
- ECサイトのバックエンドでStep Functionsを使っていたらSagaパターンになっていた話
- 主な業務フロー：カート → 情報入力 → 確認画面 → 購入完了
- 画面遷移ごとにかかる時間を平準化できるよう、DB書き込み処理を分散している
- ワークフローを途中から再開させるために、別のステートマシンを別途起動して保存状態を引き継ぐ方式にした
- 現状、決済後の処理失敗時はSNS経由でBacklogに通知して人力対応している（改善したい…）
- 実際良かったのか？AWSさんに答え合わせをしてもらったら「Sagaパターンに近いのでは」と紹介をうけた
- 補償トランザクションが現状人力なのが、Sagaパターン「みたいなもの」ポイントｗ
LOWYAが辿った負荷対策の軌跡 〜GraphQL Cachingの実装に至るまで〜 / 小原 一真さん
- ECサイトのセールのたび、EC2で稼働するDBの手動スケーリングに追加費用が発生してしまっていた
- 都度ベンダーさんへの見積もりから必要なためめちゃ時間がかかっていた
- フルスクラッチで自社開発を決意。ECS on Fargateで、GraphQLを用いたSPA構成を採用
- 一大イベント「LOWYAの日」を無事に乗り越えた！が問題がいくつか発生していた
- Auroraのコネクション枯渇、決済クォータに引っかかる、メール遅延、多重注文など
- 普段から意識していない部分や閾値周りに注意
- New Relicによる事前の可視化で解決できた
- その後、テレビ放映（ふなっしー砲）で倍の規模のリクエストが発生し503エラーを出してしまった
- Lambda@Edgeのクォータ抵触が原因。
- CloudFrontでGraphQLをキャッシュしてレイテンシー＆コストを削減した。キャッシュ管理もCDNで一元化できて楽
- AWSのプロトタイピングプログラム（裏メニュー）を活用してスピーディに設計できた
Mobageの監視環境をAWSで構築する話 / 鈴木 正樹さん
- モバゲーの監視環境はEC2ベースのため、運用コストが高かったり状態監視ができないという課題があった
- 「閾値監視」だけでなく「状態監視」（障害が続いているかの監視）も重要！
- AWSなのでCloudWatchを用いてフルマネージド化を目指した。設定のIaC化も可能
- Slack通知にはSNSやAWS Chatbotも活用
- CloudWatchエージェントならSystems ManagerのRun Commandで全EC2向け一括操作ができる
第3部
自分の仕事を破壊したい！各API活用をサーバーレスで実現している設計や運用など。 / 山下 光洋さん
AWSコースの講師をほぼ毎日やっているために本家Dev Dayへ参加できなかった山下さんの貴重なLT！
- AWSトレーニング運営の日直自動化をした話（講師がちゃんと来てるか電話で確認をする担当）
- Amazon Connectで電話を自動でかけるAPIをLambdaのPythonコードで呼び出す
- 電話に出たか否かの確認をタイムスタンプのメトリクスで判断している
- AWSトレーニング講師の仕事も破壊したい！ OpenAIで「クローン山下」を作って実験中
ガス会社がサーバレスと IoT を活用して to B 向け省エネサービスを構築した話 / 小笠原 元気さん
- AWSを活用したPoCが上手くいったので、対外向けサービスの内製開発にも挑戦することに
- サーバーレス構成＆ソラコムAPIを活用
- IoTプロジェクトは顧客単価が安いため、低コストで始められるサーバーレス向き
- AWSのIoT Device Shadowを使ってデバイス向けのPub/Subを実現した
- 監視にはAmazon Managed Grafanaを検討したが、認証など課題が多くFargateでGrafanaを自前運用することに。時系列データベースとしてAmazon Timestreamを利用した
- IaCにはCDKを利用。API GatewayをCDK化しなかった（Open APIを使えるため）ために環境移行が大変だった
- ちなみにCDKはPythonを使ったが、TypeScriptの記事が多いため移行したいと考えている
失敗から学んだCDK Construct Libraryを利用した開発の効率化 / 河越 光さん
- CDKのレイヤーは厳密には4つある（L1、L2、L2.5、L3）
- CDKのL2.5へ自分たち特有のユースケースを取り込んで実装＆再利用していくとよい
- projenを使えばAPI定義などを自動生成してくれる
- 実際やってみると沼もあり。共通化しすぎてもアジテリティを損ねてしまう。車輪の再発明も発生
- 組織特有の実装例：Slack通知をコンストラクト化する等（ワークスペースID探すの大変なので）
マイクロサービス化と組織の重要性 ~ChatGPTを活用し、ドメイン分割をイベントストーミングでやってみよう！ / 小板橋 由誉さん
- JTCで数あるマイクロサービスを見ていると、設計が崩壊してしまっている事例も多い
- マイクロサービスの定義は、ビジネスドメインごとに分割されていて「単独でデプロイ」できること
- 理想的なマイクロサービスは、1つのビジネス要件に対して実装先のサービスが1つで済むこと
- 実際うまくいってない。理由の例：流行ってるからマイクロサービスにしてみたい。流行ってるからk8s…などなど
- マイクロサービスのメリット：疎結合、技術選定、ビジネス要求
- 理想的なチームはTwo-Pizza。各チームが権限を持ってサービスを所有している状態
- AWSのサービス選定：なるべくサーバーレスにする。以上！（どうしても無理ならレイヤーを落とす）
- ドメイン分割のためにイベントストーミングでワークショップをやってみよう
- ファシリテーションが一番難しいので、ChatGPTを使って自動化を検討してみた。キャッシュはMomentoが便利
特別企画
本家Dev Dayの裏話を深掘り!? / AWSJ 金森さん ＆ 運営メンバー
- AWS Dev Dayの運営はマーケチームだが、コンテンツ面はSAがサポートしている
- 選考の流れ：全員でCFPを全部読む → 趣旨と合わないセッション（インフラ寄りとかサービス紹介系）を外す → 人気投票＋運営メンバーの選定でまず10件程度を決める → 全体バランスを見てジャンルを絞りつつ追加選定して仮決め → タイムテーブル化してみてバランス見つつ再調整
- 三浦さんのCFPを添削シミュレーション：書き方は理想的。タイトルがキャッチー、注目要素を含めており、アブストも整理されている。たまたまSagaパターンネタが複数あったことが影響したり、Sagaパターン「のようなもの」といった表現が学術的に嫌気された側面はあったかも（今年の運営メンバーのキャラ的に）
- AWSがDev Dayといった開発者向けイベントをやる理由はまさに、サーバーホスティングではなくSQSやS3から始まったAWSの方向性（エンジニア志向）がよく表れている
最後に
現地＆オンラインでご参加くださった方、ありがとうございました！！
今日のイベントは有志が無償で運営しています。参加費がわりにアンケートへのご回答よろしくお願いいたします🙇♂️