AWS Summit 2024 が 6 月 20 日、21 日にかけて開催されたので、参加してきました。 多岐にわたるセッションに参加し、多くの学びを得ることができたので、その内容をまとめます。
聴講したセッションの中でも特に自分の学びになったと感じたセッションは以下でした。
- AWS-01 Dive deep on Amazon S3
- S3 の効率的な利用方法について具体的な知識が得られた
- AWS-28 大規模クラウドインフラ設計、構築案件の歩き方
- 大規模インフラの設計と構築における課題を具体化し、対応のために実践的な進め方と方針を示していただいた
- AWS-57 規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法
- インフラは見ていたけどアプリケーション自体がどう区切られているのか自身があまり理解できていなかったところに分割方法や考え方を教えてくれた
- AWS-59 アーキテクチャ道場 2024！
- 発想を毎年広げてくれるのでお勧め
このブログでは アーキテクチャ道場 を除く3つのセッションについてメモした内容と感想をまとめます。 個人的にとっていたメモを整理したものなので、セッションの内容と少しずれている可能性もあります。
詳細な内容は AWS Summit 2024 の公式サイト上から資料をダウンロード、配信をみることができるのでぜひご活用ください。
AWS-01 Dive deep on Amazon S3
公式概要
Amazon S3 は、業界トップクラスのスケーラビリティ、耐久性、セキュリティ、パフォーマンスを提供するクラウドオブジェクトストレージです。このセッションでは、Amazon S3 の基盤となるアーキテクチャを掘り下げ、どのようにしてスケーリングと伸縮自在性を実現しているのかを見ていきます。データ保護方法、データの耐久性に対する考え方や文化、そして新しい Amazon S3 Express One Zone ストレージクラスがどのように一貫したパフォーマンスを実現するかについて知っていただき、利用者の機械学習ワークロードや、データ分析を支える仕組みの理解を深めます。
登壇者
焼尾 徹 様
アマゾン ウェブ サービス ジャパン合同会社
シニアストレージスペシャリストソリューションアーキテクト
内容のメモ
Amazon Simple Storage Service （S3） とは
350 以上のマイクロサービスが組み合わさることで S3 が実現されている。
リアクティブ（問い合わせベースの運用）な運用から脅威モデリング（事例ベースで運用を共有）をベースにした運用、プロアクティブ（予測して事前に改善していく）と変遷してきたサービス。
フロントエンド、インデックス層、ストレージ層に分かれておりそれぞれに工夫がなされている。
フロントエンドの理解
1PB/秒を超えるピークトラフィックに対応するため、以下の工夫がなされている。
- マルチパートアップロード
- 大きなファイルは分割して並列でデータを転送する
- これによってどれかのアップロードに失敗しても全部やり直さなくて済む
- もちろんダウンロードも分割されており、並列でダウンロードされたものが結合され 1 つのオブジェクトに戻っている
- DNS で複数の S3 エンドポイントを返す
これらは 0 から実装すると大変だが、AWS SDK を使えば勝手にやってくれる。AWS SDK を使うのがよい。
- S3 mountpoint について
インデックスの理解
ストレージ層で使われる Key/Value がインデックス。特定のストレージに特定インデックスのオブジェクトが配置されることになる。 インデックスにはプレフィックス（バケット名のあとに続く任意の文字列）が用いられており、特定のインデックスへのアクセスが集中した際にはプレフィックスを分割することで負荷を分散させている。
プレフィックスでインデックスを作っているため、以下に留意するとトランザクション/秒（TPS）が向上する
ストレージ層の理解
ストレージそうでは以下の工夫で 11 9s（イレブンナイン）の耐久性を実現している。
- リクエスト時の整合性チェック
- 冗長してデバイスに格納
- デバイスが故障しても他の箇所から復元をし、継続的に冗長性を保つ
- マルチ AZ でデータを保存し、AZ 障害が発生してもデータを復元できる
- 定期的に耐久性を監査
- チェックサムを定期的に検査
Amazon S3 Express One Zone ストレージクラス
Express One Zone も整合性チェックや冗長して保存、耐久性の監査を通じて 11 9s の耐久性を持つが、マルチ AZ ではなく単一 AZ に保存される性能重視のストレージクラス。 つまり AZ 障害でデータを失う可能性はある。
- なぜこのようなストレージクラスが作られたのか
- 中のオブジェクトを利用するアプリケーションと同一の AZ に配置することで I/O 性能が上がる
- リクエストにおける CreateSession も最初のみにしてパフォーマンスを上げる
- 用途の例
誤削除への対策
人間が間違えて消してしまうとどうしよもない。以下の対策が存在。
- S3 Versioning
- S3 Replication
- S3 Object Lock
- Backups
感想
すぐに活用できる例として S3 のプレフィックスの話は非常に有用だと感じた。裏側がわかるとうまくツールを扱えるようになる例だなと感じる。 機械学習のデータセットを保存する際には Express One Zone が使えるというのも知識として持っておくとよいと感じた。
セッションの中では S3 というのがいかに大きなトラフィックを捌いているか、また様々な工夫がされていることを知ることができた。 その工夫に乗るためには以下を念頭に今後 S3 を利用していきたい。
dig s3.amazonaws.com A +short すると確かにばらけていることが確認できた。こうやってリクエスト先を分散させているんですね
AWS-28 大規模クラウドインフラ設計、構築案件の歩き方
公式概要
クラウド技術のコモディティ化により、エンタープライズ分野では近年、AWS 上での大規模なアプリケーション開発が一般的になりつつあります。これを支えるクラウドインフラ設計についても、求められる非機能要件の高度化と関連する AWS サービスの多様化に伴って、多人数でのチーム設計やアプリケーションチームとの効果的な連携が求められることが増えてきました。 本セッションでは、AWS Professional Services の豊富な実績を元に、クラウドインフラの設計・構築およびテストを円滑に進める上での実践的知見をご紹介します。
登壇者
仲谷 岳志 様
アマゾン ウェブ サービス ジャパン合同会社
プロフェッショナルサービス本部 プリンシパルビッグデータコンサルタント
内容メモ
大規模インフラには以下の特徴、解くべき課題がある。 またそれぞれの解決策として以下がある。
- 関係者が増える
- 設計の骨組みづくり
- アプリ / インフラチームの責任分解 -コーディングルール
- 想定外が増える
- クリティカルパスの特定
- 展開手順の整備
- コスト管理は今すぐ始める
- 堅牢さが求められる
- クラウドリソースのテスト
- 静的解析
内容が非常に濃かったので自分の中でなるほどーと思ったところに絞って書きます。 詳細はぜひぜひ資料をダウンロードして読んでほしいです。
設計の骨組みづくり
まずやるべきことは「設計書一覧の作成」
可能な限り洗い出して詳細に書くことで抜け漏れ防止や誰が担当するかを明確にできるなどのメリットがある。
例として出された設計書一覧が以下でかなり数が多い。自分の設計がいかに不足していたかを感じる。
設計書一覧（例）
- 設計基本方針
- アカウント設計
- アカウント設計
- Organizations 設計
- SCP 設計
- ネットワーク設計
- ゲートウェイ設計
- コンピューティング設計
- Lambda 設計
- ECS/Fargate 設計
- EC2 設計
- データ設計
- Aurora 設計
- DynamoDB 設計
- S3 設計
- OpenSearch Service 設計
- ElastiCache 設計
- インテグレーション設計
- セキュリティ設計
- セキュリティ設計方針
- 暗号化設計
- 認証認可設計
- 脆弱性対策設計
- セキュリティ監視設計
- セキュリティサービス設計
- 運用設計
- 運用設計方針
- 監視設計
- 通知設計
- バックアップ・リストア設計
- 基盤メンテナンス設計
- ハウスキーピング設計
- 上限管理設計
- 踏み台設計
- タグ設計
- コスト管理設計
- 証明書管理設計
- 災害対策設計
- ログ設計
- ログ設計方針
- 収集設計
- 加工設計
- 蓄積設計
- 検索設計
- CICD 設計
- CICD 設計方針
- ブランチ戦略
- 利用ツール
- IaC コーディングルール
- IaC テスト方針
- レポジトリ設計
- パイプライン設計
- デプロイ設計
- ECR 設計
... など
設計書の一覧を作ったあとの流れ
- 設計書項目の整理
- いわゆる ADR を残す
- 設計の理由を残すべき
- 今後の設計改定への布石にもなる
- 詳細設計書の取り扱い方針を決める
- ex. 初版は IaC + 文書、以降は IaC を正とする
- 進捗を定義する
静的解析について
大規模な開発は IaC で管理される。IaC 開発におけるポイントはセキュリティチェック。 セキュリティリスクの洗い出しをできるように個々の開発環境やレビュープロセス、 CI/CD に静的解析ツールを導入することが必要。 ただし例外はあるので都度設定すること。
CloudFormation や CDK であれば cdk-nag を利用する手がある。
その他
- コスト管理は今すぐ始めるべき
- Dev は失敗する環境、だからこそ高騰するコストがある
- ex. CloudWatch Logs に大量のトレースが流れる可能性
- クリティカルパスの特定
- クリティカルパスの例
- 手動展開のほうが合理的なパターン
- IaC で実施できないパターン
- 大規模インフラの特徴「社内調整や申請が必要」
- 思わぬところで時間を食いかねないので早めに確認すべき
- クリティカルパスの例
- 展開手順の整備
- 大規模開発の場合、段階的に繰り返し展開することになる
- IaC/手動/申請を区別し、依存関係を踏まえつつ手順を組み立てる
- 展開手順は自分が読むわけではないのでローコンテキストで書く
- IaC に置けるテストの考え方
感想
設計書の設計書を作るという概念が自分にはなかったので非常に参考になりました。明日から実践していこうと思います。
またこの設計書の扱いを明確に「初版は IaC + 文書、以降は IaC を正とする」と決めてしまうのも非常によいと感じた。
コードを見ればいい派、理由がわからないから文書で残すべき派、いままでいろいろな派閥と出会ってきてあまり決めずにいた。セッションの中で最初は人の会話をスムーズにさせるため文書を用い、その後はメンテナンス性を加味してコードを正とするのはよい落としどころになりそう。
セッションの中では設計書の例が示されたり、静的解析のツールの例が出されたりと非常に具体的な内容が多く含まれていました。 自分のなかで持てていなかった Tips を多く得ることができたので、今後のエンジニア人生に活かしていきたいです。
AWS-57 規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法
公式概要
フレームワークを活用した典型的なWeb三層のアプリケーションで開発をスタートし、最初はスピード感のある開発が行えていたのに、徐々に機能が追加されていき、気がつくと様々な機能が密結合になり、単一のデータベースを様々な機能が利用していて、変更の影響がどこにあるか分かり難くなってきます。次第に機能追加に時間がかかるようになり、古いコードを変更することが怖くなり、元のコードを残したまま、コードを追加するようになって益々複雑化していきます。このような状況を改善するためには適切な粒度でサービスを切り出して置き換えていくことが必要です。では、どのようにすれば正しい粒度でサービスを分割ができるでしょうか。本セッションでは DDDをベースとしてEvent Storming を活用した境界づけられたコンテキストの発見による具体的なサービスの分割方法をご紹介します。
登壇者
福井 厚 様
アマゾン ウェブ サービス ジャパン合同会社
プロトタイプ＆カスタマーエンジニアリング本部 Developerスペシャリスト ソリューションアーキテクト
内容メモ
Why なぜリアーキテクチャが必要になるのか︖
小規模ならばフレームワークの機能によってシンプルな実装ができる。ビジネスロジックも CRUD や OR マッパーで済む。
- ただし成長するにつれて...
- データの呼び出しが複雑に
- ビジネスロジックがほかのレイヤに漏れだす
- 結果
- コードの見通しが悪くなり機能追加や修正の影響が不明瞭になる
- ライブラリやスキーマ変更の影響が広く
→ マイクロサービス化を検討。
- マイクロサービスのメリット
- デプロイの影響範囲が狭まる
- 機能的な自立性と単一責任の原則
- 開発速度の向上
- スケーリングの最適化
- コストの最適化
- マイクロサービスがいい選択肢ではないとき
- サービスの分割単位が不明瞭
- 開発メンバが少数
- 単純な CRUD のみの小規模アプリケーション
- 正当な理由がない
How どうやってサービスを分割するのか
高品質なソフトウェアモデルを設計するためのソフトウェア開発手法であるドメイン駆動設計（DDD）を活用。
ポイントはビジネスドメインを理解し、境界付けられたコンテキストからドメインを定義すること。 つまりビジネスに精通した人の言語が伝わる範囲で責務を分割する。
ex. ユーザでも見るシステムからしたら「入札者」「購入者」「配送先」
ドメイン分割の手段として Event Storming があり、業務から境界付けられたコンテキストとモデルを導き出すことができる。 Event Storming を理解するためのおすすめブログとして SODA さんの以下の記事をおすすめしていただきました。
ドメインモデルの実装方法
以下の流れでテストは作成
詳細は以下の書籍を確認。 「テスト駆動開発」︓Kent Beck（著）和⽥ 卓⼈（翻訳） オーム社 2017/10/14
- ビジネスドメイン全体をコンテキスト境界で分割
- コアドメインとサブドメインを定義
- ドメイン間をドメインイベントでつなげる
- 出来上がったモデルを論理アーキテクチャに落とし込む
- 論理アーキテクチャから物理アーキテクチャに落とし込む
感想
自分があまりソフトウェア開発手法周りに触れてこなかったものの話は聞く DDD や TDD といった手法についてざっと流れを知ることができ、勉強になった。 周りでも分割が必要なのではないかと考えられるシステムがあったり、実際にこういった手法を取り入れている方がいるのをちらほら見かける。 話を聞きつつ参考として教えていただいた書籍やブログを通して知見を深めていきたい。
ドメイン駆動設計を自分が過去ちらっと聞いた際に「ドメイン知識に精通した人」に沿ってシステムを設計すると聞いて、システムを作るならそのドメインに精通してなきゃつくれないのは当然では？エンジニアが作りたいものを作ってしまう人間であるがゆえに出来上がってしまった考え方か？と思ってしまっていました。今回の話を聞いて少なくともその認識は違うな、と感じました。 正直イメージがつかないところも多かったが、大局を見ることができたと思われるので気になるところを深堀しつつ日々に生かしていきたい。
まとめ
今回の AWS Summit では Level 300 以上のものを中心に自分の分野に関連するセッション、ちょっとずれているけど薄くかかわりのあるセッションを中心に聞いてきました。 自分にとってちょうどいいレベル感で様々なお話を聞くことができたおかげで自分の知識や考え方が広がったり、深めたりできました。直近で使えるものから将来的に使えるものまで広く知ることができたので、今後の活動に活かしていきたいです。
