いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！
今回は2025.03.26（水）に開催した[つながりテック #2 AWSトークで締めくくる年度末LT大会 ~初登壇も大歓迎！~]に参加しましたので、アウトプットとしてイベントレポートを執筆しました。
初見の方でもサクッと読めるように平易な表現で執筆しておりますので、お気軽に読んでいただければ幸いです。
誤字脱字、わかりづらい表現に関しては極力なくすように心がけていますが、リアルタイムで執筆しておりますので、誤字脱字があるかもしれません。
イベントページ
目次
- イベント概要
- LT
- S3静的ホスティング+Next.js SSGで格安webアプリ構築
- 新卒エンジニア、Amazon SageMakerに$10課金してしまった
- S3Tabe関連
- AWSで考えるSRE 〜サービスの信頼性〜
- 個人的 2025年1Q Amazon Bedrockニュース
- Amazon Q Developer 運用調査機能について(仮)
- AWSの仮想化技術について深掘りする(仮)
- FOCUSダッシュボードで実現するマルチクラウドコスト可視化
- Bedrockの利用料を削減！Novaで実現するプロンプトルーティング
- AWSのコストについて再考してみる
- まとめ
イベント概要
つながりテックの第2回イベントのテーマはAWS！ 取り組んでいることや経験談、Tips、学びなど、どんな内容でもOK！
初登壇、大歓迎です！！ JAWS DAYSの熱に触れて「自分も登壇してみたい！🔥」となった方、いますよね？？ 是非挑戦していただければと思います！！
見ているだけでも楽しめるカジュアルな雰囲気なので、ぜひお気軽にご参加ください。
新しい気づきや学びを得て、2024年度を締めくくりましょう！ みなさんのご参加をお待ちしています！
LT
S3静的ホスティング+Next.js SSGで格安webアプリ構築
- 自己紹介
- AWSキャッチアップしたての方
- アーキテクチャ
- TodoリストをNext.jsで作成してみた
- CloudFrontをフロントにAPI Gatewayを利用
- API Gatewayオリジン
- オリジンパスをAPI側に切り替える
- 今後の展望
- より、Amplifyに近づけていくことを目標にしていく
新卒エンジニア、Amazon SageMakerに$10課金してしまった
- 自己紹介
- 社会人1年目のアプリケーションエンジニアの方
- 大学院時代に地理情報を触っていた
- Amazon SageMaker AIとは
- ざっくり言えば、Amazon製の機械学習プラットフォーム
- Sagemakerでの悲劇
- Notebook止めたが課金が止まっていなかった
- なぜかData Wranglerが動いていた
- サポートへ問い合わせてドメイン停止も行った
- トラブルから得た知見
- DataWraglerはインスタンスで実行
- ノートブックインスタンスを停止しても課金は止まらない
- ドメイン削除が最善手といったわけではない
- サポートに問い合わせれば課金停止方法を教えてくれる場合も
- サービスページにもまとめられている
S3Tabe関連
参考サイト
- 自己紹介
- 製造業でDXなどを行っている
- DuckDB周りを触っている
- 登壇のきっかけ
- DuckDB公式でAWS S3について取り上げられた
- Icebergとは
- ざっくり言えば楽に接続できるデータベース
- Iceberg REST Catalog API経由だと楽に接続できる
- 実装方法
- S3 Tableを作成する：作成先リージョンを間違えると作り直しするはめに
- AthenaでIcebergテーブルを作成：簡単なテーブルで問題ない
- IAMポリシーを作成する：S3Table関連の権限を付けておく
- Lamdba LayerにDuckDBを追加しておく：C++なので一癖加工が必要
- Lamdba関数を実行する
- シークレット認証情報などを行っておく
- まとめ
- Icebergのテーブル表示はできるようになった
- リポジトリやシークレット回りに関しては改善の余地がある
AWSで考えるSRE 〜サービスの信頼性〜
登壇資料
参考サイト
- お伝えしたいこと：SREとはどのような役割を果たすのかについて
- SREとは
- ソフトウェアエンジニアに運用チームの設計を依頼した時に出来上がるもの
- 源流はソフトウェアエンジニアがポイント
- バイブルは「SREサイトリライアビリティエンジニアリング」がある
- 初心者は「SREをはじめよう」から入ったほうがいい
- ソフトウェアエンジニアに運用チームの設計を依頼した時に出来上がるもの
- サービスの信頼性
- ミッションクリティカル・耐障害性など様々な要素が
- そのうえで、根本としてあるのがWebサイトの信頼性がある
- （例）決済サービスで正しく決済処理ができる
- インフラだけでなくソフトウェア知識も求められる
- SLI
- ユーザ影響に直接関係する定量的に観測可能な値
- レイテンシー・エラーレート・スループットなど
- CUJベースであることが大切
- （個人的考察）ユーザ満足度を踏まえたアラート設計が必要といことね
- ユーザ影響に直接関係する定量的に観測可能な値
- SLO
- サービスの安定性の目標値
- 対外的なSLIと違い、対象は社内向け
- サービス信頼性に関してはSREだけでなくエンジニアとサービスオーナーと合意形成を図ることが大切
- 定義する際に必要なのはステークホルダーへの信頼と開発防衛
- 進め方として低い値から進めていくのがいい（99％から始める）
- サービスの安定性の目標値
- AWSでのSRE
- 複数サービスを用いながら開発を行っていく
- サービスごとのSLOを組み合わせて計算していく
- 監視するポイントはアラート、メトリクス、ログ
- トイル
- 手動で行っている反復可能な自動化
- とにかく撲滅することがポイント
- CI/CDやIaCなどを活用していく
- まとめ
- サービス信頼性を向上させるためにSREを導入するのがいいのでは
個人的 2025年1Q Amazon Bedrockニュース
- 自己紹介
- SKYARCH所属のエンジニアの方
- インフラ瀬敬・構築・アプリ設計などを行っている
- 大学時代にはニュートリノを追っかけていた
- 趣味として読書（約1,300）
- re:Inventから今までのアップデート
- Amazon Novaシリーズの登場がビッグポイント
- 基盤周りのアップデートも興味深いが限定プレビュー状態
- AIモデルに関してもDeepSeekが登場したり
- Amazon Bedrcokが大阪リージョンで利用可能
- Claude3.5・Titan Text Embedding V2のみが利用可能
- 今後、RAG対応もできるようになっていくのでは
- （個人的考察）国内拠点のみでクロスリージョンが完結できるかも
- アジアリージョン全体でのルーティングのため国外リージョンのモデルが
- Claude 3 Sonnetが一部リージョンでレガシー
- メールでも連絡が来ているため、新しいモデルに変えていく
- Claude 3.7 Sonnetがリリース
- ハイブリット推論モデルの登場
- ざっくり言えばClaude3.5の改良版
- （個人的考察）がっつり触れていないから触らないとなぁ
- Amazon Q Developer CLIエージェント半端ない
- AWS環境の情報取得ができるようになっている
- まとめ
- Bedrock関連のアップデートは多いがキャッチアップは楽しい
Amazon Q Developer 運用調査機能について
- 自己紹介
- とある事業会社のPMの方
- レガシーシステムの運用
- 人力で頑張る・現地到着したら作業が始まる
- つらみがある
- Amazon Q Developerの運用機能が登場して救われる
- Amazon Q Developer運用調査機能
- 現在プレビュー機能のため、バージニア・オレゴンのみで利用可能
- CloudWatch Alarm設定で連携できる
- バッグエンドで高負荷をかけて調査してみた
- Amazon Q Developerで分析してくれる
- 10分くらいで最初の改善提案を行うこともできる
- Slackでも通知対応が可能
- まとめ
- 東京でのGAを期待している
- クロスリージョン推論を利用しているので国内のみに閉じない
- 未知の障害・大規模障害への備えに使える
AWSの仮想化技術について深掘りする
参考サイト
- 自己紹介
- 会社ではChampと呼ばれている
- Nitro Systemとは
- ざっくり言えば、EC2の仮想化を実現するサービス
- インスタンス内から外部ネットワークへのパケットの流れを見てみる
- Nitroカードでのパケット処理
- Txリングバッファへの投入
- OSがENA経由でパケットをキューに書き込む
- （個人的考察）分散処理している感じなんですかね～
- パケット読み取りと処理
- NitroカードはキューからVPC情報の参照・検証を行う
- ルートテーブル情報・NACL評価・セキュリティグループ評価など
- 物理的な位置マッピング
- AWS内部のマッピングサービスから宛先インスタンスの物理的な場所を取得する
- コネクショントラッキング
- 初回パケットは通常通りの通信を行っている
- ２回目以降はキャッシュ処理を行うため高速化
FOCUSダッシュボードで実現するマルチクラウドコスト可視化
参考サイト
- 自己紹介
- 大手SIer所属のプロジェクトマネージャーの方
- コンサル業務も担っている
- マルチクラウドにおけるコスト管理の課題とFOCUS
- 今までは各クラウドベンダーのコスト管理ツールを統合していた
- データ標準化されていないためカスタマイズが必要
- FOCUSの登場によって統合管理できるようになっている
- AWSでの取り組み
- FOCUSダッシュボードのQuickSightで構築するといったワークショップもある
- ワークショップだけではデータ統合ができるわけではない
- Google Cloudワークショップで統合版のワークショップが公開されている
- まとめ
- FOCUSスキーマを利用することでデータ標準化を自動的に行えるようになる
Bedrockの利用料を削減！Novaで実現するプロンプトルーティング
- LLM利用の課題
- 優秀なモデルだと費用が高くなる
- 安いモデルだと回答の質が下がってしまう
- いい感じで使い分けができるようになりたい
- Intelligent Prompt Routingで解決できる
- Intelligent Prompt Routing
- 各モデルの応答品質を予測し使い分けを行う
- 現在プレビュー段階・英語のみ対応・利用可能なリージョンは限定的
- とりあえず独自開発してみた
- アーキテクチャ
- NovaLiteを選んだ理由
- マルチモーダルに対応
- 低コスト・高速対応・十分な精度が出せる
- 独自で作ったメリット
- 日本語完全対応
- リージョン制限もなく、モデル選択も自由に行える
- コストについて
- コスト削減を行うことができやすくなった
- ルーティング判断に科にても.0.46秒と高速処理ができる
- 入力トークンに関しても15秒ほどで実装できる
- 工夫した点
- Nova Liteへのプロンプト設計とルーティング判断
- プロンプト結果をバイナリ化している
- エラー処理に関してモデルの得意分野に合わせて変えている
- 推論パラメータの最適化
- Nova Liteへのプロンプト設計とルーティング判断
- NovaLiteを選んだ理由
- まとめ
- プロンプトルーティングを自作することでカスタマイズ性を持たせる
- （個人的考察）アプリ開発を通じてサービスへの理解が強化されますよね
AWSのコストについて再考してみる
- 自己紹介
- これから締め切りドリブンでCB・All Certの申請を行う
- インフラとコスト
- 月額1000ドル、月額1500ドルだったら
- コストだけ見たら1000ドルだが、バックがEC2だった場合
- 果たして月額1000ドルが安いのか
- 月額1000ドル、月額1500ドルだったら
- 本日やりたいこと
- 実際に合った例をもとにAWSコストを考えてみる
- アプリケーションの前提
- 24/365稼働し捨てう
- 不定期なアクセス集中が発生
- 月次で軽微なリリースが発生している
- 月額1000ドル構成（すべてEC2）の場合
- 不定期なアクセス集中が発生
- 対応には間違いなく人手が必要
- 月次で軽微なリリースを実施
- 定期的なメンテナンス作業が必要
- エンジニア単価（100万）と仮定したら1.5日分にしかならない
- 人道的な体制だと総コストが高くなってしまう
- 不定期なアクセス集中が発生
- 月額1500ドル構成（ECS）の場合
- 不定期なアクセス集中
- スケールでの対応ができそう
- 月次の軽微なリリースが発生
- CI/CDの導入で工数削減ができそう
- 前提条件が変わったら月額1500ドルが最適解でない場合も
- 不定期なアクセス集中
- まとめ
- インフラコスト以外にも目を向けることで幸せになることもある
まとめ
AWSに関するアーキテクチャ話、技術話を聞きながらやはりAWSは面白いなと再認識しました。そのうえで、Bedrockルーティング判断を自作した話はすごすぎると思いましたので、私も何かしらの自主開発を行っていきたいと思いました！！
最後まで、記事をお読みいただきありがとうございました！！