【[セッションレポート] 規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法（AWS-57） #AWSSummit】
いわさです。 本記事は 2024 年 6 月 20 - 21 日の 2 日間開催された AWS Summit Japan 2024 のセッションレポートとなります。 このセッション、個人的に大変興味があったものの当日は GameDay に参加しており現地で聴講することが出来ませんでした。 しかしすぐにオンデマンド配信がされているではありませんか。やったぜ。 オンデマンド配信の動画リンクと資料のダウンロードは以下です。 動画の視聴と資料のダウンロードには AWS Summit Japan のマイページのログインが必要です。 オンデマンド配信リンク - 規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法（AWS-57） AWS Summit Japan - セッション資料一覧 概要 6/21(金) 14:50 - 15:30 セッションタイトル：「規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法（AWS-57）」 フレームワークを活用した典型的なWeb三層のアプリケーションで開発をスタートし、最初はスピード感のある開発が行えていたのに、徐々に機能が追加されていき、気がつくと様々な機能が密結合になり、単一のデータベースを様々な機能が利用していて、変更の影響がどこにあるか分かり難くなってきます。次第に機能追加に時間がかかるようになり、古いコードを変更することが怖くなり、元のコードを残したまま、コードを追加するようになって益々複雑化していきます。このような状況を改善するためには適切な粒度でサービスを切り出して置き換えていくことが必要です。では、どのようにすれば正しい粒度でサービスを分割ができるでしょうか。本セッションでは DDDをベースとしてEvent Storming を活用した境界づけられたコンテキストの発見による具体的なサービスの分割方法をご紹介します。 スピーカー 福井 厚 アマゾン ウェブ サービス ジャパン合同会社 プロトタイプ＆カスタマーエンジニアリング本部 Developerスペシャリスト ソリューションアーキテクト レベル Level 400: 上級者向け アジェンダ なぜリアーキテクチャが必要になるのか？ どうやってサービスを分割するのか ドメイン駆動設計とイベントストーミングによる分割 非機能要件を論理アーキテクチャにマッピング ドメインモデルをインフラストラクチャコードから分離 セッションレポート ちなみにこのセッションはほとんど AWS の話出てこないです。最後に API Gateway - Lambda - DynamoDB の場合にクリーンアーキテクチャを当てはめるところで例で出てくるくらいでしょうか。 実際にマイクロサービス化を進めるにあたっては AWS サービス云々よりも前段階が非常に難しくそこで失敗することが多いのでは、むしろ非 AWS 領域にフォーカスしたこのセッション内容は多くの方が聞きたいことなのではないでしょうか。 前半 冒頭でまず以下の流れでマイクロサービス化の必要性についておさらいしています。 よくある Web 三層アーキテクチャ・モノリスの強み 小規模な開発では、フレームワークの機能によってシンプルに実装が可能 ー出たベースはトランザクションで一貫性を容易に確保 ビジネスロジックは単純なCRUDや、フレームワークが提供するORマッパーでの実装が中心 少人数での開発に最適 デプロイメントはモノリスでシンプル モノリシックアーキテクチャで成長し続けた際に出てくるつらみ 異なる機能から共通のデータへアクセス パフォーマンスも課題に 利用者が増えてくるとスケーラビリティの確保が必要 モノリスだとスケール単位もモノリスになり、スケールしなくても良いものまでスケールしてしまう アプリはスケールアウトして負荷分散しやすいが、データベースに負荷が集中する。また、データベースはスケールアップ戦略を取ることが多いが、上限があることが多い ビジネスロジックが他のレイヤーに漏れ出していってしまう コードの見通してが悪くなり、機能追加や修正が及ぼす影響が不明に 共通ライブラリの修正による影響が大きくなる データベーススキーマの変更が他の機能に影響を与える デプロイメントが大変になりリリース頻度が低下する マイクロサービスアーキテクチャ 採用理由 デプロイの影響範囲を小さくする 機能的な自律性と単一責任の原則 開発速度の向上 スケーリングの最適化 コストの最適化 やめたほうが良いケース […]
https://dev.classmethod.jp/articles/aws-summit-2024-aws-57/
DevelopersIO RSS feed【非公式】
npub16u6…5q5c
2024-06-24 04:13:46
Author Public Key
npub16u6jx85wavk5n0kw5r46ma7dunupsp7acmtn3xys7keqvlsfjxpsar5q5cPublished at
2024-06-24 04:13:46Event JSON
{
"id": "eb86eec065d660957d297877b3e194a375535ff24473ff638a597f6b16be1e23",
"pubkey": "d735231e8eeb2d49becea0ebadf7cde4f81807ddc6d7389890f5b2067e099183",
"created_at": 1719195226,
"kind": 1,
"tags": [
[
"r",
"https://dev.classmethod.jp/articles/aws-summit-2024-aws-57/"
],
[
"proxy",
"https://dev.classmethod.jp/feed/#https://dev.classmethod.jp/articles/aws-summit-2024-aws-57/",
"rss"
]
],
"content": "【[セッションレポート] 規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法（AWS-57） #AWSSummit】\nいわさです。 本記事は 2024 年 6 月 20 - 21 日の 2 日間開催された AWS Summit Japan 2024 のセッションレポートとなります。 このセッション、個人的に大変興味があったものの当日は GameDay に参加しており現地で聴講することが出来ませんでした。 しかしすぐにオンデマンド配信がされているではありませんか。やったぜ。 オンデマンド配信の動画リンクと資料のダウンロードは以下です。 動画の視聴と資料のダウンロードには AWS Summit Japan のマイページのログインが必要です。 オンデマンド配信リンク - 規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法（AWS-57） AWS Summit Japan - セッション資料一覧 概要 6/21(金) 14:50 - 15:30 セッションタイトル：「規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法（AWS-57）」 フレームワークを活用した典型的なWeb三層のアプリケーションで開発をスタートし、最初はスピード感のある開発が行えていたのに、徐々に機能が追加されていき、気がつくと様々な機能が密結合になり、単一のデータベースを様々な機能が利用していて、変更の影響がどこにあるか分かり難くなってきます。次第に機能追加に時間がかかるようになり、古いコードを変更することが怖くなり、元のコードを残したまま、コードを追加するようになって益々複雑化していきます。このような状況を改善するためには適切な粒度でサービスを切り出して置き換えていくことが必要です。では、どのようにすれば正しい粒度でサービスを分割ができるでしょうか。本セッションでは DDDをベースとしてEvent Storming を活用した境界づけられたコンテキストの発見による具体的なサービスの分割方法をご紹介します。 スピーカー 福井 厚 アマゾン ウェブ サービス ジャパン合同会社 プロトタイプ＆カスタマーエンジニアリング本部 Developerスペシャリスト ソリューションアーキテクト レベル Level 400: 上級者向け アジェンダ なぜリアーキテクチャが必要になるのか？ どうやってサービスを分割するのか ドメイン駆動設計とイベントストーミングによる分割 非機能要件を論理アーキテクチャにマッピング ドメインモデルをインフラストラクチャコードから分離 セッションレポート ちなみにこのセッションはほとんど AWS の話出てこないです。最後に API Gateway - Lambda - DynamoDB の場合にクリーンアーキテクチャを当てはめるところで例で出てくるくらいでしょうか。 実際にマイクロサービス化を進めるにあたっては AWS サービス云々よりも前段階が非常に難しくそこで失敗することが多いのでは、むしろ非 AWS 領域にフォーカスしたこのセッション内容は多くの方が聞きたいことなのではないでしょうか。 前半 冒頭でまず以下の流れでマイクロサービス化の必要性についておさらいしています。 よくある Web 三層アーキテクチャ・モノリスの強み 小規模な開発では、フレームワークの機能によってシンプルに実装が可能 ー出たベースはトランザクションで一貫性を容易に確保 ビジネスロジックは単純なCRUDや、フレームワークが提供するORマッパーでの実装が中心 少人数での開発に最適 デプロイメントはモノリスでシンプル モノリシックアーキテクチャで成長し続けた際に出てくるつらみ 異なる機能から共通のデータへアクセス パフォーマンスも課題に 利用者が増えてくるとスケーラビリティの確保が必要 モノリスだとスケール単位もモノリスになり、スケールしなくても良いものまでスケールしてしまう アプリはスケールアウトして負荷分散しやすいが、データベースに負荷が集中する。また、データベースはスケールアップ戦略を取ることが多いが、上限があることが多い ビジネスロジックが他のレイヤーに漏れ出していってしまう コードの見通してが悪くなり、機能追加や修正が及ぼす影響が不明に 共通ライブラリの修正による影響が大きくなる データベーススキーマの変更が他の機能に影響を与える デプロイメントが大変になりリリース頻度が低下する マイクロサービスアーキテクチャ 採用理由 デプロイの影響範囲を小さくする 機能的な自律性と単一責任の原則 開発速度の向上 スケーリングの最適化 コストの最適化 やめたほうが良いケース […]\nhttps://dev.classmethod.jp/articles/aws-summit-2024-aws-57/",
"sig": "0d036e1488562f3a14a30f206d86c5605b21d01b172212fd2cb94fcb199c539177f3415da2dd503267aa139d902c30eef38582c301c7674fbd73622d84e6046c"
}