[レポート] AWS 上のモダン .NET アプリケーション用の専用データベース #XNT304 #reinvent

いわさです。

掲題のチョークトークに参加したので内容を紹介します。
前半がセッションで、後半がホワイトボードを使った Q&A タイムでした。

Purpose-built databases for modern .NET applications on AWS

セッション概要

Previously, the only database choice that .NET developers had was either Microsoft SQL Server or Oracle. Today, developers are moving away from one-size-fits-all monolithic databases and are increasingly building modern cloud-native applications using multiple purpose-built databases. AWS offers a choice of relational, key-value, wide-column, document, in-memory, graph, time-series, and ledger databases, with each purpose-built database solving a specific problem or usage scenario. In this chalk talk, learn about AWS purpose-built databases for .NET developers that meet the scale, performance, and manageability requirements of modern applications built for the cloud.

スピーカー

• Runeet Vashisht, Sr Solutions Architect, AWS
• Craig Bossie, Solutions Architect, Microsoft Workloads, Amazon Web Services

レベル

300 - Advanced

セッション内容

まずエンタープライズアプリケーションの歴史・進化についておさらい

• メインフレーム
• 複数のハードウェアに分散
• 3層アーキテクチャー
• モダンデザインパターン（マイクロサービス化とサービスごとの適切なデータストアの選択）

これまでの背景と選択肢

• 一般的に企業はエンタープライズ .NET アプリケーションのバックエンドとして SQL サーバーを選択してきた
  • パターン、プラクティス、ライブラリなど .NET アプリケーションで SQL Server を使用するすべてが文書化されている
  • 開発者にとって馴染みがあり使いやすい

これから

• 分散型クラウドアプリケーションを構築するためのツールやパターンが出てきた
  • ソーシャルメディアのように高度に相互接続されたデータベース
  • IoTデバイスからのデータ
  • 製品カタログのように特定の製品構造やデータ構造を持たないデータ。変更される可能性もある
• RDBMS アクセスパターンしかない場合非効率になってしまっている
  • アプリケーションに追加のオーバーヘッドが必要

専用（目的にあわせて構築された）データベース

• 特定のデータ構造とアクセスパターンを処理するために作成されたデータベース
  • 全てのデータをリレーショナルデータとして効率的にモデル化出来るわけではないという背景
  • クラウドアプリケーションを構築するために必要なスケール機能、パフォーマンス、可用性を提供する多数のデータベースサービスを提供している

ユースケースの例

• ユーザープロファイルやセッションデータなどのデータを扱っている場合はキーバリュー構造なので DynamoDB を使用してハイパフォーマンスに処理をする
• 製品データやステートメントデータ・フォーマットなどを扱っている場合、Document DB のようなドキュメントスタイル
• 高性能、低レイテンシな非永続化データに Elasticache for Redis / Memory DB for Redis

.NET での選択肢

• Document DB であれば Mongo DBドライバーを使用
• .NET Core を使用すると Redis をシームレスに統合出来る
  • StackExchange.Redis : 業界標準のオープンソースドライバー
• SQL Serverを使う選択肢ももちろんある
  • RDS for SQL Server を使用出来る
  • 独自の SQL Server よりも運用上のオーバーヘッドを取り除ける
  • 商用データベースのパフォーマンスが必要だが、高価なライセンスが不要であれば Aurora PostgreSQL/MySQL を試せる
  • ADO ドライバーや EntityFramework プラグインなど同じ方法で統合可能
  • Babelfish もある
  • アプリケーションのコードをほとんどまたは全く変更せずにメリットを得ることが出来る
  • 互換性について Compass というツールを使って確認出来る

他にも専用データベースはある

• Amazon Neptune: ソーシャルデータや不正検出
• Amazon Timestream: シーケンシャルおよび時系列データベース
• Amazon QLDB: 普遍で暗号学的に検証可能なトランザクション。金融アプリやサプライチェーン
• Amazon Keyspaces (for Apache Cassandra): トレーニング、監視、フリーとマネージャーなどを適切に配置する高度に分散された高性能データベース

Q&A

これは .NET 固有の話で他の言語は無関係か？

全ての言語で利用出来る DynamoDB SDK のようなものがある。 ただし、 SQL Server のように .NET に偏っているデータベースもある。

大規模なデータベースシステム(6000 の RDS インスタンス)が専門の DBA チームで構成されている。顧客が新しいテクノロジ（分散台帳や DynamoDB）を要求しておりチームが神経質になっている。良い方法はあるか？

SQL Server は引き続き重要なデータベースソリューションととして必要だという前提がある。
その上で差別化につながらない真夜中のメンテナンス作業などは自動化出来る。
クエリのパフォーマンス改善など、より付加価値の高い作業に集中出来る

様々なデータストアのスキルが必要になる。スキルセットを構築するために何が出来るか

• Skill Builder で無料トレーニングが提供されている
• AWS と契約がある場合はトレーニングを受けることも出来る

さいごに

前半のセッション部分は re:Invent 2021 の以下のセッションの振り返りと同じような内容でした。

ただし、今回は現場のエンジニアの声にソリューションアーキテクトの方が回答しててとても良かったです。
印象としてはグローバルでも .NET エンジニアはなかなかモダナイズが進んでいない印象を持ちました。

チョークトーク開始後に隣の方が Visual Studio を開いて NuGet でライブラリ導入し始め、セッション聞きながら学んだことをその場で試しててすごいなと思いました。

なお、セッション終了後にセッションルーム外に出てみるとおやつタイムが始まっていました。