2026 年 7 月 20 日週、私はサンパウロで中南米各地のテクニカルビルダーと 3 日間過ごす機会に恵まれました。ここでは、深く掘り下げたセッション、ハンズオンワークショップ、お客様やパートナーとの会話が盛りだくさんの地域の技術イベントに参加しました。私が最も感銘を受けたのは、単一のセッションではなく、同じ部屋にいる機会はめったにない技術コミュニティのエネルギーでした。人々はコーヒーを飲みながらアーキテクチャのアイデアを交換し、ホワイトボードに解決策をスケッチし、到着したときよりも長い「試してみたいこと」のリストを手にして帰っていきました。私たちが構築するすべてのツールにおいて、それを取り巻くコミュニティこそがテクノロジーを定着させていることを思い出させてくれます。 このコミュニティの精神は、 7 月 27 日週の最大のインフラストラクチャニュースとうまく結びついています。それは、AWS をビルダーが実際にいる場所の近くに届けることに関するものです。 それでは、7 月 27 日週の AWS ニュースを見ていきましょう… 主なトピック ギリシャのアテネの AWS ローカルゾーン : AWS はギリシャのアテネに新しいローカルゾーンを開設しました。これは、Amazon S3 と Amazon EBS ローカルスナップショットをサポートする EMEA の 2 番目のローカルゾーンです。これにより、ギリシャ国内でデータを保存および処理して、ローカルのデータレジデンシー要件を満たすのに役立ちます。アテネローカルゾーンは、Amazon EC2 (C7i、M7i、および R7i インスタンス)、ワンゾーン低頻度アクセスストレージクラスの Amazon S3、Amazon EBS、および Amazon ECS をサポートしています。 AWS ローカルゾーンは、AWS インフラストラクチャを大勢の人口や業界のハブの近くに配置しています。これにより、リアルタイムゲーム、メディア制作、金融サービスなど、数ミリ秒のレイテンシーを必要とするアプリケーションを、エンドユーザーが実際にいる場所で実行できるようになります。ギリシャのビルダーは、レイテンシーの影響を受けやすいワークロードをローカルで実行すると同時に、低レイテンシーを必要としないサービスのために最も近い AWS リージョンにシームレスに接続できるようになりました。これにより、独自のデータセンターインフラストラクチャを管理しなくても、レイテンシーが最適化されたハイブリッドアプリケーションを柔軟に設計できます。詳細については、 AWS グローバルインフラストラクチャと持続可能性に関するブログ投稿 をご覧ください。 7 月 20 日週のリリース 7 月 20 日週のリリースのうち、私が注目したリリースをいくつかご紹介します: AWS 上の Claude Opus 5 : Anthropic の Claude Opus 5 を使用できます。これは、これまでで最も先進的な Opus モデルであり、多くの分野で Claude Fable 5 のトップクラスのインテリジェンスに匹敵する、Opus レベルの料金体系でご利用いただけます。Amazon Bedrock では、デフォルトでゼロデータ保持 (ZDR) が有効になっている Claude Opus 5 を提供しています。これにより、Claude Fable 5 とは異なり、データガバナンス要件を満たしながら、Opus の最高レベルのインテリジェンスを提供できます。Claude Opus 5 にアクセスするには、Amazon Bedrock と Claude Platform on AWS の 2 つの方法があります。詳細については、 詳細なブログ投稿 にアクセスしてください。 .NET 用の AWS Lambda 永続実行 SDK が一般公開されました : カスタムの進捗追跡を実装したり、外部のオーケストレーションサービスを統合したりしなくても、Lambda の永続関数を使用して、回復力のある長時間実行ワークフローを C# で構築できるようになりました。SDKは、支払い処理パイプライン、AI エージェントオーケストレーション、ヒューマンインザループ承認などの複数ステップのアプリケーションに最適です。進行状況を自動的にチェックポイントで確認し、実行を最大 1 年間停止できます。お客様がサーバーレスワークフローを構築している .NET 開発者である場合、これによって手作業で記述していたプラミングの大部分が不要になります。 Amazon Bedrock AgentCore では、トレースとログを 1 つのロググループにまとめることで、統一されたオブザーバビリティを実現できるようになりました : Amazon Bedrock AgentCore は、エージェントのトレースとプロンプトを、エージェントのログと同じ Amazon CloudWatch ロググループに配信するようになりました。以前は、テレメトリは送信先に分散され、トレーススパンは共有ロググループに送られ、プロンプト、入力、出力は別のロググループに送られました。そのため、1 回のエージェント呼び出しをデバッグするには複数の場所を検索する必要がありました。呼び出しを 1 か所でデバッグし、きめ細かなアクセス制御とカスタマーマネージドキー (CMK) 暗号化を個々のエージェントレベルで適用できるようになりました。 Amazon Connect がより自然なエージェント音声体験を提供 : Amazon Connect は、現在、ポルトガル語、スペイン語、フランス語、イタリア語、日本語、韓国語、タイ語を含む 50 以上の言語で、より自然で人間に聞こえるエージェント型音声体験をサポートするようになりました。100 を超える新しい音声オプションと会話の改善により、AI インタラクションがよりスムーズに聞こえるようになりました。Connect のエージェント型セルフサービスにより、AI エージェントは顧客の口調や感情に合わせて、音声やデジタルチャネル全体で理解し、推論し、行動に移すことができます。顧客が実際に話す言語のうち、これまでよりもはるかに多くの言語で、発信者に対して自然に感じられるコンタクトセンター体験を構築できるようになりました。 Amazon SageMaker Unified Studio が Amazon OpenSearch をサポートするようになりました : Amazon OpenSearch の検索データやログ分析データを、Amazon SageMaker Unified Studio の他のデータ資産と一緒に直接クエリして分析できるようになりました。この接続により、OpenSearch の運用検索データを Amazon Redshift、Amazon S3、リレーショナルデータベースなどのソースからのデータと、すべて単一の管理された環境内で組み合わせることができます。アプリケーションログをトランザクションデータと組み合わせてインサイトを引き出すなど、分析ワークロードと運用ワークロードを相互に関連付ける必要がある場合に特に役立ちます。 Amazon CloudWatch がコーディングエージェントのインサイトを発表 : Amazon CloudWatch により、エンジニアリングリーダーは AI コーディングツールが組織全体でどのように価値をもたらしているかを把握できるようになりました。コーディングエージェントインサイトは AWS 用の Claude アプリゲートウェイと統合されているため、追加のインストルメンテーションなしで Claude Code からテレメトリを収集できます。また、Codex や GitHub Copilot などのエージェントもサポートしています。チームが AI コーディングの採用を拡大するにつれて、OpenTelemetry で構築されたメトリクスを使用してその投資収益率を測定できるようになりました。カスタムインストルメンテーションは必要ありません。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: AI エージェントの評価: Strands と AgentCore を使った本番環境ブループリント : Strands Agents と Amazon Bedrock AgentCore を使用して、本番環境に移行する前後に AI エージェントを評価するための実践ガイド。エージェントをプロトタイプから本番環境に移行している場合、この投稿は上記の AgentCore Observability のアップデートに役立ちます。エージェントの品質を直感ではなく体系的に測定する方法を説明しています。 AWS CloudFormation カスタムリソースデプロイのためのマルチリージョンの耐障害性の構築 : 単一リージョンに問題が発生した場合でも、コードとしてのインフラストラクチャのデプロイの信頼性が維持されるように、マルチリージョンの耐障害性を実現するために CloudFormation カスタムリソースを設計する方法を学んでください。 Amazon Simple Email Service (SES) 料金プランのご紹介 : Amazon SES では、E メールの量が増えてもコストを予測できる料金プランが提供されるようになりました。大量に送信する場合、請求が大幅に簡素化されます。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits : AWS Summits は、クラウドや AI のコミュニティが一堂に会し、つながり、学び、最新のテクノロジーを探求するための無料のイベントです。カレンダー全体をご覧になって、2026 年後半にお近くで開催されるサミットを見つけてください。 AWS Community Days : コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。ラテンアメリカにお住まいの方は、8 月 22 日に開催される AWS Community Day Belo Horizonte をお見逃しなく。登録は awscommunityday.com.br で受付中です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 7 月 27 日週のニュースは以上です。８ 月 3 日週の Weekly Roundup もお楽しみに! この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

大規模なデータ量を運用するうえで、運用面での重要な課題に直面します。Similarweb では Apache HBase でこれらの課題に直面し、 Amazon DynamoDB で解決策を見出しました。 Similarweb は、 Web サイトのトラフィック、アプリの利用状況、市場トレンドに関する AI 駆動のインサイト を提供するデジタルインテリジェンスプラットフォームであり、企業が競合をベンチマークし、成長戦略を最適化するのに役立ちます。 私たちは既存の Apache HBase インフラストラクチャでスケーラビリティと運用上の複雑さの問題が増大しており、より柔軟で効率的な代替案を模索することになりました。本記事では、データストレージを Apache HBase から DynamoDB へ移行した過程を紹介します。技術的な課題、移行アプローチ、データモデリング戦略、コスト最適化テクニック、そして得られた主なメリットについて議論します。DynamoDB へ移行することで、パフォーマンスとスケーラビリティが向上し、メンテナンス負荷が軽減され、チームはインフラ管理よりもイノベーションに注力できるようになりました。学んだ教訓と、この移行が業務オペレーションに与えた影響についても探っていきます。 背景 私たちの Web アプリケーションでは、ユーザーに大量のデータを提供するために堅牢なデータベースソリューションが必要です。そのソリューションは、データを効果的に保存し、迅速に取得し、ユーザーインターフェイスに結果を返す前に集計、グルーピング、ソートなどの操作を実行する必要があります。これを実現するため、データの性質とクエリパターンに基づいた 2 つのアプローチを採用し、Web アプリケーションを応答性が高くインタラクティブに保つよう設計しています。 最初のアプローチは、ユーザー入力に依存する動的クエリや、サイトグループのべき集合のデータを計算するような複雑な計算に関するものです。これは膨大な数の組み合わせとなり、事前計算は現実的ではありません。そのため、これらのクエリには Firebolt のようなクラウド分析データベース (OLAP システム) を使用しています。Firebolt は、JOIN、GROUP BY、その他の SQL ライクなクエリ操作を含む複雑なクエリパターンにも使用しています。これらのデータベースは、ETL ベースの事前集計に適さない大規模データセットのオンザフライ処理に優れています。 一方、2 つ目のアプローチでは、予測可能で事前計算可能なアクセスパターンを持つ機能について、DynamoDB のようなキーバリュー (KV) ストアを使用しています。定期的な ETL プロセスでデータを事前計算することにより、DynamoDB は集計情報への高速で簡素なアクセスを提供し、パフォーマンスとスケーラビリティのバランスを取りながらユーザーに応答性の高い体験を提供します。 トラフィックとエンゲージメントデータを取得するための要件 事前計算データの利用方法を示すために、プラットフォームの UI で表示している、Web サイトのトラフィックとエンゲージメントの経時的な推移という典型的なユースケースを見てみましょう。 図 1: Similarweb の Traffic and Engagement レポートでは、ユーザーは分析するサイト (1) を選択し、日付範囲 (2) を選び、世界全体または特定の国などの地理的範囲 (3) を設定できます。これらの選択を行うと、グラフには選択した期間における訪問数やユニークユーザーといった主要メトリクスが表示されます。 例えば example.com などの Web サイトの訪問統計を、サイト名、日付、国 (ISO コード)、訪問数といった詳細とともに保存しています。   Site Country (ISO) Date Visits TimeOnSite BounceRate … example.com 840 2026-01-22 7 15.2 7 example.com 840 2026-01-23 11 11.7 1 example.com 840 2026-01-24 3 20.3 4 example.com 840 2026-01-25 12 13.2 5 example.com 840 2026-01-26 9 19.1 7 アクセスパターンとしては、example.com の特定の日付範囲における全国の訪問データを取得したり、米国 (840) のような特定の国の訪問データをクエリしたりすることが考えられます。このシナリオでは、ETL プロセス中に日付、国、サイトの各組み合わせに対する訪問数を事前に計算して保存することで、これらの一般的なアクセスパターンに対して迅速な応答時間を実現しつつ、クエリ時の計算オーバーヘッドを最小限に抑えることができます。 これらの事前計算されたメトリクスは単純に見えますが、Similarweb の規模では、その背後にある書き込み負荷とクエリの多様性が既存の HBase クラスタを限界まで押し上げました。私たちのケースでは、データは継続的に書き込まれるのではなく、Spark ジョブを使用して日次、週次、月次といったスケジュールされた間隔で大規模なバッチで取り込まれます。 大規模スケールと柔軟なアクセス Similarweb のトラフィックとエンゲージメントデータセットは膨大で、合計 255 テラバイト (TB) を超えます。データを継続的に取り込むトランザクションアプリケーションとは異なり、私たちの分析パイプラインは大きなバーストで呼吸します。データを新鮮に保つため、 1 テーブルあたり約 70 億レコード を、数時間で完了させる必要があるタイトなスケジュールのバッチで取り込んでいます。 しかし、データを書き込むことは戦いの半分にすぎません。保存後、このデータは多様で複雑な読み取りパターンに対して即座に利用可能でなければなりません。ユーザーは単純なキー検索以上のことを行います。彼らは複数の次元でデータを切り分けて、競合をベンチマークし、トレンドを分析します。 次の図は、移行前のハイレベルなデータフローを示しています。 図 2 (移行前): 生のイベントはデータレイクに到達し、Spark ETL が日次集計を計算し、バルク書き込みで結果を HBase に保存します。.NET バックエンドはサイトと国のメトリクスをキー (および日付) で読み取り、Traffic and Engagement UI に提供します。すべての矢印はデータフローを表しています。 単純なキーバリュー検索を超えて 特定のフィルタリングパターンに対して 1 桁ミリ秒の読み取りを提供しながら、大規模な書き込みスパイクに対応できるデータベースソリューションが必要でした。具体的には、任意のサイトに対して以下の 4 つのアクセスパターンをサポートする必要がありました。 サイトレベルの集計: サイトの全トラフィックを取得。 SELECT * WHERE Site = {site} 特定の国の内訳: 特定の国にドリルダウン。 SELECT * WHERE Site = {site} AND Country = {country} 時系列トレンド: 特定の期間の履歴を取得。 SELECT * WHERE Site = {site} AND Date BETWEEN {start} AND {end} 複雑な組み合わせ: 国と日付範囲の両方でフィルタリング。 SELECT * WHERE Site = {site} AND Country = {country} AND Date BETWEEN {start} AND {end} これを達成するために、理想的なデータベースは以下の 4 つの厳格な基準を満たす必要がありました。 高い書き込みスループット: 数時間で数十億レコードを取り込む。 多用途なクエリサポート: テーブル全体をスキャンせずに、前述の次元ベースのクエリを処理。 パフォーマンスを保ったスケーラビリティ: ピーク書き込み時でも高い読み取りパフォーマンスを維持。 コストの透明性: 請求書で驚くのではなく、実行 前に コストを見積もれる予測可能な料金モデルを提供。 HBase が壁にぶつかった理由 HBase は長年にわたって私たちに役立ってきましたが、Similarweb の規模では、徐々に「使用するデータベース」から「運用するシステム」へと変化していきました。中核的な制限は生の能力ではありませんでした。それは、非常に大規模なバッチ書き込みと常時稼働の読み取りに対する厳しい期待を組み合わせた後に現れた運用リスクと不安定さでした。 1. RegionServer の不安定性がオンコール対応の原因に 繰り返し発生するインシデントの原因は、HBase の RegionServer がクラスタの他の部分と同期しなくなったり、ダウンしたりすることでした。RegionServer がドリフトしたり誤動作したりすると、ホストするリージョンの可用性とレイテンシに影響を与える可能性があります。回復が可能な場合でも、それは不安で時間がかかるものであり、頻繁に発生したため、実質的な運用負担となっていました。 2. ストレージとディスクのアップグレードが悪夢 大規模な HBase 環境におけるディスク管理とアップグレードは、常に非常に摩擦の大きいものでした。分散システムにおけるディスク変更は単独のイベントではありません。それはパフォーマンス、安定性、運用手順に波及します。ルーチンとなるべきインフラ作業がしばしば実質的なリスクを伴う複数ステップのメンテナンスに変わり、特に取り込みウィンドウや読み取り SLA を保護しようとしているときには厳しいものでした。 3. アーキテクチャの利点が私たちのアクセスパターンと一致しなかった HBase のワイドカラムモデルは、大きな行から列のサブセットを読み取るときに真価を発揮します。私たちの場合、アクセスパターンはしばしばキーに対するメトリクスの完全なセットを読み取ることを必要としていたため、システムの最も強力な設計上の利点を一貫して享受することなく、システムの運用コストを支払っていることになっていました。 4. データベースがピーク向けにサイジングされていたため高コスト テラバイト規模のバッチロードは短く激しい書き込みピークを生み出す一方で、製品は依然として高速で予測可能な読み取りを必要としていました。ピーク向けにサイジングされた常時稼働クラスタを維持することは、1 日のほとんどで実際に使用していないキャパシティに対して支払うことを意味していました。 これらの課題は単一の壊滅的な障害として現れたわけではありません。それらは累積する運用負荷として現れました。深夜の呼び出しが増え、クラスタの健全性に費やす時間が増え、ルーチンメンテナンスのリスクが増加しました。その複合化するオーバーヘッドが、フルマネージドな代替案を探すことを促しました。 DynamoDB がこれらの課題にどう対処するか DynamoDB により、以下が可能になりました。 クリティカルパスからクラスタ運用を排除。 DynamoDB では、リージョンサーバーをプロビジョニングする必要がなく、リバランスもなく、インフラ層でのキャパシティプランニングも手動で行う必要がありません。それにより、データベースの健全性に関連する日常的な運用作業と障害モードの数が直接削減されました。 永続的なオーバープロビジョニングなしでバッチ取り込み向けにスケール。 私たちの書き込みパターンは予測可能です。書き込むレコード数と完了までの時間ウィンドウがわかっています。DynamoDB ではキャパシティをダイヤルとして扱うことができます。取り込み実行の直前に プロビジョンド書き込みキャパシティユニット (WCU) を即座にスケールアップし、完了次第すぐにスケールダウンします。これにより、24 時間 365 日大規模なクラスタを稼働させ続けるのではなく、コストをバッチウィンドウに合わせることができました。 書き込みスパイク中も読み取りパフォーマンスを安定的に維持。 UI の背後にあるアクセスパターンは、主にキーベースの検索と日付範囲クエリです。DynamoDB のパーティション化されたアーキテクチャと、 パーティションキーとソートキー に対する Query 操作 により、テーブルが非常に大きく成長し、取り込みジョブが並列実行されている場合でも、これらの読み取りを一貫して低レイテンシで提供できます。 コスト動作を明示的かつ予測可能に。 DynamoDB のキャパシティとリクエストパターンが私たちのワークロードにきれいにマップされるため、レコード数、アイテムサイズ、予想されるクエリの形状から書き込みと読み取りのコストを見積もることができます。これにより、コストモデリングは事後的な驚きではなく、設計の一部となりました。 耐障害性とディザスタリカバリオプションの改善。 DynamoDB は、すぐに使えるマネージドバックアップとリカバリプリミティブを提供します。マルチリージョンのニーズに対しては、 DynamoDB Global Tables でリージョン間でデータをレプリケートできるため、読み取りをローカルで提供でき、リカバリは大規模クラスタを圧力下で再構築することに依存しません。 この基盤が整ったことで、私たちのワークロード固有の部分、つまり高スループットで効率的に取り込む方法と、低コストでアクセスパターンを満たすためのキーモデリングに集中できるようになりました。次の図は、移行後のデータフローを示しています。 図 3 (移行後) : 事前計算されたトラフィックとエンゲージメントメトリクスは、2 つのパスを通じて提供されます。予測可能で低レイテンシのアクセスのための DynamoDB に支えられたキーバリューレーンと、動的でアドホックなクエリのための Firebolt を使用する分析レーンです。.NET バックエンドはそれに応じてリクエストをルーティングします。歴史的に、レーン A は HBase を使用していました。それを DynamoDB に置き換えました。 データモデリング DynamoDB のパフォーマンスとコストのメリットを最大限に引き出すためには、実際のクエリパターンに基づいてデータモデルを設計することが重要でした。私たちの目標は、応答時間と読み取り/書き込みキャパシティ使用量の両方を最小化する効率的なアクセスパスを作成することでした。 Traffic and Engagement の例を再度見てみましょう。コアアクセスパターンには、日付範囲全体にわたるサイトの訪問データの取得と、オプションで国によるフィルタリングが含まれます。 単純なアプローチ: パーティションキー 最初のアプローチは、次のようなフラットでユニークなパーティションキーを作成することかもしれません。 PK = {site}_{country}_{date} Primary key Visits TimeOnSite BounceRate PK example.com_840_2026-01-21 4 24 12.31 1 か月分のデータ、例えば 2026 年 1 月の米国 (国コード 840) における example.com への訪問を取得するには、31 個の個別のキーを生成し、BatchGetItem リクエストを発行します。 example.com_840_2026-01-01 example.com_840_2026-01-02 ... example.com_840_2026-01-31 この設計は機能しますが、スケールでは非効率でコストがかかります。単一の BatchGetItem リクエスト内では、各アイテムの取得が個別の読み取り操作としてカウントされ、ペイロードサイズが小さくてもアイテムごとに 1 つの読み取りキャパシティユニットを消費します。 最適な設計: パーティションキーとソートキーを持つコンポジットキー よりスケーラブルなモデルでは、パーティションキーとソートキーを持つ コンポジットプライマリキー を使用します。 パーティションキー (PK): {site}_{country} ソートキー (SK): {date} Primary key Visits TimeOnSite BounceRate PK SK example.com_840 2026-01-21 4 24 12.31 このセットアップでは、DynamoDB の効率的な Query API を使用して、日付範囲にわたるサイトと国のペアのすべてのレコードをクエリできます。 Query(PK="example.com_840", SK BETWEEN "2026-01-01" AND "2026-01-31") これにより API コールの数が減り、ソートキーに対する範囲クエリを使用することで読み取りコストが大幅に削減されます。 コスト比較: Query 対 BatchGetItem サイトと国の組み合わせごとに 500 日分のデータを取得し、各エントリが約 200 バイトであるユースケースを考えてみましょう。 注: RCU はアイテムサイズに応じて 4 KB チャンクでスケールします。結果整合性のある読み取りでは RCU が半分になります。 アプローチ 読み取り API RCU 計算 推定コスト フラット PK BatchGetItem 500 アイテム × 1 RCU = 500 RCU $0.065 コンポジット PK + SK Query 100 KB / 4 KB = 25 RCU $0.00325 節約: コンポジットキー設計を使用することで 20 倍以上安価 。 全世界のユースケース コンポジットキーモデル ( PK = {site}_{country} 、 SK = {date} ) は、サイト、国、日付範囲でフィルタリングされた一般的なクエリを効率的にサポートしますが、 全国にわたる訪問データをクエリ する必要がある場合に課題が生じます。例えば、example.com の全世界の訪問を、全期間または特定の日付範囲で取得する場合です。 SELECT * WHERE Site = 'example.com' SELECT * WHERE Site = 'example.com' AND Date BETWEEN '2026-01-01' AND '2026-01-31' 既存のスキーマでは、 国コードがパーティションキーに埋め込まれて おり、これはパーティション間で書き込みと読み取りの負荷を均等に分散するために不可欠です。しかしこれは、 データをクエリするには国を知る必要がある ことも意味し、グローバル集計のユースケースには望ましくありません。 シンプルですが非効率な解決策は、すべての国別パーティションにわたって Query API コールをファンアウト することです。 # ファンアウト Query: すべての国にわたるサイトの訪問を取得 results = [] for country in country_codes: # ~200 ISO 3166 コード pk = f"example.com_{country}" response = query( TableName='TrafficTable', KeyConditionExpression="PK = :pk AND SK BETWEEN :start AND :end", ExpressionAttributeValues={ ":pk": pk, ":start": "2026-01-01", ":end": "2026-01-31" } ) results.extend(response['Items']) # 国レベルのレコードを集計して単一の世界規模ビューにする worldwide = {} for item in results: date = item['SK'] visits = item['visits'] worldwide[date] = worldwide.get(date, 0) + visits # worldwide = {"2026-01-01": 148200, "2026-01-02": 136400, ...} 機能的には正しいものの、このアプローチにはいくつかの欠点があります。 高コスト : サイト/日付クエリごとに 200 以上の Query リクエスト。 増加したレイテンシ : 200 のクエリにわたって結果をクエリし集計することで、応答時間が大幅に増加する可能性があります。 BatchQueryItem なし : BatchGetItem とは異なり、複数の Query リクエストを単一の API コールにバッチ処理するネイティブな方法はありません。 運用オーバーヘッド : 200 以上の並列クエリの管理は、アプリケーションに負荷をかけ、スロットリングのリスクを増加させる可能性があります。 ファンアウトのコストと複雑さを発生させずに効率的なグローバルクエリをサポートするため、ETL プロセス中に特別な合成国コード (例: 999) を導入しました。実際には、ETL パイプラインの一環として集計された世界規模メトリクスを事前計算して保存し、専用の「グローバル」パーティションに書き込みます。これは、世界規模データに指定されたパーティションキー PK = {site}_999 を使用することで実現します。 Primary key Visits TimeOnSite BounceRate PK SK example.com_840 2026-01-21 4 24 12.31 example.com_999 2026-01-23 33 17 16.5 これにより、 単一の Query リクエスト で世界規模データをクエリできます。 Query(PK="example.com_999", SK BETWEEN "2026-01-01" AND "2026-01-31") このようにして、読み取り時のパフォーマンスオーバーヘッドがなく、複数ではなく 1 つの Query リクエストを使用するためコストも削減されます。 もちろん、「999」アプローチにもコストがかかります。サイトと日付ごとに追加の世界規模ロールアップを計算する必要があるため ETL の複雑さが増し、サイト国レコードごとに追加のアイテムを永続化するためストレージも増えます。それでも、システムをエンドツーエンドで見ると、明らかな勝利です。読み取り時から書き込み時に作業をシフトし、200 以上のファンアウトクエリの必要性を排除し、アプリケーション側のオーケストレーションを減らし、一貫してより高速な世界規模読み取りを実現します。実際には、追加の ETL とストレージコストはクエリコストとレイテンシの節約によって上回られるため、ソリューション全体としてはより安価で高速になります。 次のセクションでは、初期データ移行と毎月のデータ取り込み中に時間とコストを節約するために、DynamoDB の機能をさらにどのように利用しているかを探ります。 DynamoDB への書き込み バッチ取り込みは私たちの分析パイプラインの心拍です。継続的なストリームではなく、Databricks 上で日次、週次、月次のスケジュールで ETL Spark ジョブをトリガーするスケジュールされた Apache Airflow Directed Acyclic Graphs (DAGs) に依存しており、それぞれが下流機能の鮮度要件に合わせて調整されています。すべての実行で、テーブルが読み取りトラフィックに対してできるだけ早く準備できるように、短い時間ウィンドウ内に DynamoDB に数十億のアイテム、しばしば数テラバイトをプッシュします。 DynamoDB は、異なるワークロードパターンに対応する 2 つの異なる キャパシティモード を提供しています。オンデマンドモードはサーバーレスで従量課金型のモデルで、トラフィック需要に合わせて自動的にスケールし、キャパシティプランニングは不要で、使用した分のみ支払います。一方、プロビジョンドモードでは、希望する読み取りと書き込みのスループットを事前に指定する必要があり、課金はこのプロビジョンされたキャパシティに基づいて行われます (完全に使用されたかどうかにかかわらず)。私たちのケースでは、書き込むレコードの総数と取り込みの時間ウィンドウが既にわかっているため、必要な書き込みキャパシティユニットを正確に計算して設定できます。これにより、スケジュールされたバッチロードに対しては、プロビジョンドモードのほうがオンデマンドよりも大幅にコスト効率が良くなります。 エンドツーエンドのバッチワークフロー Airflow がロードをスケジュール DAG パラメータには、テーブル名とソースから読み取る日付範囲が含まれます。 ジョブはピークの重複を避けるためにずらされます。 Databricks Spark が ETL を実行 Spark のパーティションは、並列処理を最大化するために DynamoDB のパーティションキーと整合します。 DynamoDB Connector for Apache Spark を使用しており、これは書き込みをバッチ化し、指数バックオフによるリトライロジックを処理します。 キャパシティはジャストインタイムでスケールアップ ターゲット DynamoDB テーブルへの最初の書き込みの前に、インフラスクリプトが UpdateTable を呼び出してテーブルのプロビジョンド書き込みキャパシティ、つまり書き込みキャパシティユニット (WCU) を計算されたピークまで引き上げます。スクリプトは、目標期間とレコード数に基づいてこのレベルを自動的に設定します。 データを並列に書き込み DynamoDB Connector for Apache Spark を使用し、プロビジョンドキャパシティに密接に整合したスループットでデータを書き込みます。通常、プロビジョンド書き込みキャパシティの約 1.1 倍を目標とし、リソースを十分に活用しつつ最適な利用率を達成するため、制御されたレベルのスロットリングを受け入れます。 キャパシティは自動的にスケールバックダウン ETL がすべてのレコードの書き込みを終えると、UpdateTable を再度呼び出してプロビジョンドキャパシティ書き込みレベルを下げる後続タスクをスケジュールします。 def run_etl(table_name, records_count, target_duration_hours=1): # ステップ 3 -- キャパシティをジャストインタイムで計算してスケールアップ desired_wcu = ceil(records_count / (target_duration_hours * 3600)) desired_wcu = clamp(desired_wcu, MIN_WCU, MAX_WCU) wait_until_table_is_active(table_name) current_wcu = describe_table(table_name).provisioned_write_capacity update_table(table_name, wcu=current_wcu + desired_wcu) # UpdateTable API wait_until_table_is_active(table_name) try: # ステップ 4 -- Spark DynamoDB Connector を介してデータを並列に書き込み spark.write(target_table=table_name, write_throughput_ratio=1.1) # プロビジョンド WCU の約 110% finally: # ステップ 5 -- キャパシティを自動的にスケールバックダウン update_table(table_name, wcu=current_wcu) # UpdateTable API wait_until_table_is_active(table_name) DynamoDB テーブルのプロビジョンドキャパシティを計算してスケールアップする Python 疑似コード Amazon Simple Storage Service (Amazon S3) からの Import Table を使用する DynamoDB への書き込みの時間とコストをさらに削減するため、HBase からの移行時および一部の定期的な書き込みに、 DynamoDB Import from S3 機能を使用して、Amazon Simple Storage Service (Amazon S3) から直接データをインポートしました。これにより、レコードごとの書き込みが不要になり、取り込み時に書き込みキャパシティユニットを消費することがなくなります。 メリット バルク取り込みで 最大 90% のコスト削減 。 ETL 取り込みのための Databricks コンピューティング使用が不要 。 ネイティブインポートによってリトライロジックが隠蔽され、運用オーバーヘッドが取り除かれた 簡素化された運用 。 従来の Spark ジョブと比較して より高速な取り込み 。 Import Table 機能は、アイテムごとの書き込み操作ではなく、取り込まれたデータの総量に基づいて課金されるため、特に私たちのケースのように小さなアイテムを持つ大きなテーブルを移行する場合、大幅なコスト削減を実現します。 S3 からのインポートワークフロー ETL 前の自動化の一環として、データは指定された S3 パスから読み取られ、Import from S3 機能でサポートされている DYNAMODB_JSON 形式に変換されます。 整形されたデータの S3 パスとテーブル定義を指定して ImportTable API を呼び出します。 モニタリングタスクがインポート完了まで進捗を追跡します。 期間ごとに別々のテーブルにデータを保存するタイミング DynamoDB の Import from S3 機能は、大規模なバックフィルにとってゲームチェンジャーですが、重要な制約があります。新しいテーブルにのみインポートできるという点です。その制限は、データセットが自然に時間でパーティション化されており、主に最近の期間でアクセスされる場合には機会となります。 月次のデータセットでは、意図的な設計を採用しました。月ごとに 1 つのテーブルを作成し、Import from S3 を使用してその月のデータをインポートし、データが古くなるにつれてそれらのテーブルのライフサイクルを管理します。 月次データに適している理由 このアプローチが特に月次ワークロードに適している理由は以下のとおりです。 バルクロードが離散的 : 各月のデータセットは通常完全なバッチとして生成されるため、インポートのクリーンな単位になります。 クエリ時の運用の簡素さ : アプリケーションは、コールドデータとホットデータを 1 つの大きなテーブルで混在させる代わりに、関連する期間テーブルにクエリをルーティングできます。 保存期間管理が簡単に : 古いアイテムを削除する代わりに、期限切れになったテーブル全体を削除できます。 コスト最適化が容易 : 古い月次テーブルは、アプリケーションロジックを変更することなく、年齢を重ねるにつれて Standard-IA テーブルクラス に移行でき、ストレージコストを削減できます。 実用的な命名規則によって自動化が容易になります。例: {table_name}_2026-01 。 エンドツーエンドの実行方法 各月について、データセットを生成し、サポートされているインポート形式の 1 つである DynamoDB JSON に変換し、新しい月次テーブルに ImportTable を実行します。 インポート後、不要になったテーブルを削除する保存期間ポリシーを適用します。 古くなった月次テーブルを Table Class Standard-IA に移行してストレージコストを節約します。 要求された日付範囲が複数の月にまたがる場合、API は関連する月次テーブルにわたってクエリをファンアウトし、結果をマージします。 期間ベースのテーブルを使用すべきでない場合 このパターンは強力ですが、万能ではありません。 日次のデータセット の場合、1 日ごとにテーブルを作成するとテーブル数が爆発し、不必要な運用オーバーヘッドが発生します。そのような場合は、単一の長期間有効なテーブルを維持し、標準的な取り込みパス (Spark 書き込み + プロビジョンドキャパシティスケーリング) を続けるほうが良いです。 経験則 期間が粗い (月次以上) で、データがバルクでロードされ、保存期間がテーブルレベルで強制できる場合は、 期間ごとに別々のテーブルを優先 してください。 期間が細かすぎる (日次) 場合、または同じ物理テーブルへの継続的な増分書き込みが必要な場合は、 単一のテーブルを優先 してください。 結論 本記事では、Similarweb が Apache HBase から DynamoDB に移行した経緯を紹介しました。この移行は、運用を簡素化し、効率的にスケールし、インフラオーバーヘッドを削減しながら、大規模に高速で信頼性の高いインサイトを提供し続ける必要性によって推進されました。 レガシーの HBase セットアップは強力ではありましたが、増大するバッチ取り込みワークフローと動的クエリ要件のニーズに応えるのに苦労していました。安定性、運用メンテナンス、スケーリングの限界などの課題が、よりモダンなサーバーレスの代替案を求めるきっかけになりました。 DynamoDB を採用することで、以下を達成しました。 インテリジェントな書き込みプロビジョニングを伴う ETL ジョブを使用した 高パフォーマンスなバッチ取り込み 。 大規模で多様なクエリパターンをサポートする 柔軟でコスト効率の高いデータモデリング 。 フルマネージドでサーバーレスな DynamoDB アーキテクチャによる 運用負担の削減 。 Amazon S3 から直接インポートすることによる 低い運用負担と高速な履歴データ移行 。 手動のクラスタ管理なしでの システム信頼性とスケーラビリティの向上 。 この移行は、データインフラのパフォーマンスと安定性を向上させ、エンジニアリングチームが機能の構築とイノベーションの推進に集中できるようにしました。DynamoDB は、私たちの分析パイプラインの強靭でコスト効率の高い基盤であることが証明されており、Similarweb がお客様にタイムリーで実行可能なデジタルインサイトを提供するというミッションを支えています。 本記事は 2026 年 06 月 16 日 に公開された “Similarweb’s migration from HBase to Amazon DynamoDB” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/similarwebs-migration-from-hbase-to-amazon-dynamodb/ 著者について Idan Lahav Idan はテルアビブを拠点とする Similarweb の R&D ディレクターです。バックエンドインフラ、プラットフォーム基盤、データエンジニアリングに深い専門知識を持ち、スケーラブルなデータパイプラインアーキテクチャの設計と、高スループットプラットフォームの複雑な課題の解決に注力しています。最近の HBase から DynamoDB への移行において、Idan は移行を可能にした基盤となるインフラ基盤の設計と管理を担当しました。 Leonid Koren Leonid は AWS のプリンシパル NoSQL ソリューションアーキテクトで、お客様が NoSQL データベースを使用して既存のアプリケーションをモダナイズし、新しいアプリケーションを設計するのを支援しています。AWS に入社する前は、2000 年代初頭からバックエンドシステムの設計と開発を行ってきました。

本記事は 2026 年 4 月 17 日 に AWS Migration & Modernization Blog で公開された「 Modernize VB6 Applications at Scale with AWS Transform Custom  」を翻訳したものです。 想定所要時間 : 90 〜 120 分 レベル : 上級 (400) Microsoft は Visual Basic 6.0 (VB6) の延長サポートを 2008 年に終了 (*) しましたが、金融サービス、保険、ヘルスケア、製造業など、数千ものミッションクリティカルなアプリケーションが依然として VB6 に依存しています。これらのアプリケーションには数十年分のビジネスロジックが含まれていますが、年々メンテナンスが困難になっています。VB6 開発者は労働市場に残る人数が減少しているため採用コストが上昇し、パッチ未適用の脆弱性はコンプライアンス違反のリスクを高め、モノリシックなアーキテクチャは AI、アナリティクス、クラウドサービスとの統合を困難にしています。 * 訳注：厳密には、VB6 の IDE のサポートは終了してますが、VB6 のランタイムはまだサポートはされています。ランタイムは Windows のライフタイムに合わせてサポート継続されていますが、対応は重大なセキュリティ問題等に限定されています。詳細は こちら を参照してください。 これらの課題は、AWS Transform custom でカスタム変換プランを作成することで解決できます。 この記事では、AWS Transform custom のエージェンティック AI 機能を活用して、組織固有のビジネスルールを維持しながら VB6 アプリケーションを大規模にモダナイズする方法を紹介します。 VB6 モダナイゼーションの課題 VB6 アプリケーションのモダナイゼーションには、単純な構文変換を超えた固有の課題があります。 AWS Transform for .NET  は .NET Framework アプリケーションの自動ポーティングを提供していますが、VB6 には固有の特性があるため、異なるアプローチが必要です。 VB6 のモダナイゼーションでは、レガシープラットフォームとモダンな .NET の間にある根本的なアーキテクチャの違いに対処する必要があります。言語レベルでは、VB6 の手続き型および COM ベースのパターンをオブジェクト指向の C# 構造にマッピングする必要があります。ユーザーインターフェースも、ActiveX コントロールを使用した VB6 フォームから Blazor や ASP.NET Core MVC などのモダンな Web フレームワークへの変換が必要です。データアクセスパターンはレガシーな ADO や DAO から Entity Framework Core の async/await パターンに移行し、COM 依存関係は .NET ネイティブの代替手段や NuGet パッケージに置き換える必要があり、エラーハンドリングは On Error Resume Next や On Error GoTo パターンから構造化された try-catch 例外処理に移行します。 サンプルアプリケーションの紹介 Salmon King Seafood (SKS)  という VB6 Multiple Document Interface (MDI) アプリケーションを使って AWS Transform custom を解説します。これは典型的なエンタープライズモダナイゼーションの課題を表すアプリケーションです。SKS は以下の特徴を持つ水産物受注管理システムです。 15 以上の VB6 フォーム – 受注、顧客管理、商品カタログ、在庫管理、承認ワークフローを含む 3 つの VB6 モジュール (modConnection.bas、modFunctions.bas、modMain.bas) – 共有ビジネスロジックとデータベース接続を含む SQLite データベース (Orders.db) – ADO データコントロールとデータバインディングを通じてアクセス 標準 VB6 コントロール – MSFlexGrid、ListView、Toolbar、ImageList、ComboBox、Control Arrays を含む MDI アーキテクチャ  – メインコンテナフォームとメニューからトリガーされる子フォーム このアプリケーションは、エンタープライズアプリケーションでよく見られる VB6 パターンを実装しています。 イベントハンドラを持つフォームベースの UI データバインディングを使用した ADO データアクセス COM ベースのコントロール モジュール内の手続き型ビジネスロジック これらの要素により、SKS はエンタープライズ VB6 モダナイゼーションで遭遇する複雑さを代表するものとなっています。 ソリューション概要 VB6 から C# へのモダナイゼーションには、AWS Transform custom の複雑な変換パターンの学習・適用機能を活用できます。エンドツーエンドのプロセスは以下のステージに従います。 評価 – VB6 アプリケーションポートフォリオのスコープと複雑さを評価する 定義 – VB6 から C# への変換パターン、ビジネスルール、コーディング標準を含むカスタム変換を定義する 実行 – 大規模に変換を実行する レビューと反復 – フィードバックループによる継続的な改善を行いながらレビューと反復を行う このアーキテクチャにより、変換定義を一度作成してテストし、数百のアプリケーションに適用できます。 前提条件 開始する前に、以下を確認してください。 AWS Transform Custom へのアクセス権を持つ AWS アカウント 。現在の料金の詳細については、AWS Transform の料金ページをご覧ください。 ATX CLI (Command Line Interface) がインストールされた MacOS または Linux 環境。詳細なセットアップ手順については、 AWS Transform custom 前提条件ガイド を参照してください。 **Windows 開発者の場合** : WSL2 (Windows Subsystem for Linux) をインストールし、Ubuntu またはその他の Linux ディストリビューションから ATX CLI を実行してください。CLI は `/mnt/c/` パスを通じてローカルコードベースを直接操作します。 変換後のアプリケーションをテストするための .NET 10 SDK 以降 コードレビュー用の Visual Studio 2022 以降または Visual Studio Code VB6 および .NET の開発知識 有効な認証情報が設定されている Git があること 環境の準備 Salmon King Seafood (SKS)  サンプルアプリケーションをダウンロードします。これには、典型的なエンタープライズ VB6 ワークロードを代表する VB6 MDI アプリケーションが含まれています。 リポジトリをローカルマシンにクローンします。 git clone https://github.com/GAPVelocityAI/SKSVB6.git  cd SKSVB6  Windows で WSL2 を使用している場合は、両方の環境からアクセス可能なパスにクローンします。 git clone https://github.com/GAPVelocityAI/SKSVB6.git /mnt/c/Projects/SKSVB6  cd <path-to-repository>  リポジトリの内容を確認します。VB6 プロジェクトファイル (SKS.vbp)、フォームファイル (.frm/.frx)、モジュール (.bas)、SQLite データベース (Orders.db) が表示されます。 ls -la *.vbp *.frm *.bas *.db  変換追跡用にリポジトリを初期化します。 git add .  git commit -m "Baseline before VB6 to C# transformation"  次に、リファレンスドキュメントを含むリポジトリをクローンします。このリポジトリには、AWS Transform にコンテキストとして渡すビジネスルールと変換例が含まれており、組織の標準に合ったコードを生成します。 git clone -b dotnet-transform-custom https://github.com/aws-samples/dotnet-genai-samples.git  ウォークスルー 以下のセクションでは、AWS Transform CLI を使用して VB6 コードをモダンな C# プロジェクトに変換する手順を説明します。 ステップ 1: VB6 アプリケーションを評価する 変換定義を作成する前に、VB6 ポートフォリオのスコープと複雑さを把握します。SKS リポジトリをクローンした状態で、ATX CLI を起動して評価を開始します。 atx custom def exec -p <path-to-repository> \  -n 'AWS/early-access-comprehensive-codebase-analysis' \  -t  パラメータ : -p: ソースプロジェクトのパス (クローンした SKS リポジトリ) -n: 変換定義名 -t: 変換に関わるすべてのツールを信頼し、実行中に AWS Transform が許可を求めて一時停止するのを防ぐ 注意 ：2026 年 5 月 1 日時点では、変換定義名は AWS/early-access-comprehensive-codebase-analysis から AWS/comprehensive-codebase-analysis に変更になっています AWS Transform custom は、シェルスクリプトなどの特定のアクションを実行するために許可を必要とします。上記のコマンドの –t 引数により、ツールはユーザーに継続的にプロンプトを表示することなく実行できます。 評価では SKS プロジェクトを分析し、フォーム数 (15 以上)、モジュール数 (3)、COM コンポーネントの依存関係 (MSFlexGrid、ListView)、データベースアクセスパターン (ADO with SQLite)、推定変換複雑度スコアを含む包括的なレポートを生成します。 この評価レポートを使用して、VB6 アプリケーションを変換する際に AWS Transform custom に追加のコンテキストを提供します。 ステップ 2: VB6 から C# へのカスタム変換定義を作成する 次に、VB6 からモダンな C# への変換パターンとルールをキャプチャするカスタム変換定義を作成します。AWS Transform custom は、提供された例、ドキュメント、ビジネスルールから学習し、これらのパターンを一貫して適用します。 対話型 CLI を起動します。 atx -t  プロンプトが表示されたら、変換の説明として VB6 to C# ASP.NET Core web application migration と入力します。AWS Transform custom は既存の変換を検索し、この特定のシナリオに該当するものが見つからない場合、カスタム変換を作成するかどうかを尋ねます。「create a new one」と入力して確認します。 図 1 – atx cli の起動 変換コンテキストとビジネスルールの提供  AWS Transform custom は、ドキュメント、移行ガイド、サンプルコードの提供を求めます。ここで組織固有の要件を追加します。SKS アプリケーションについては、そのアーキテクチャに関するコンテキストを提供します。 Salmon King Seafood (SKS) という VB6 MDI アプリケーションがあります。ソースコードは <path-to-repository> にあります。注文受付、顧客管理、製品カタログ、在庫管理、承認ワークフローなど、15 以上のフォームがあります。3 つのモジュール (データベース接続用の modConnection.bas、ユーティリティ関数用の modFunctions.bas、アプリケーションのエントリ ポイント用の modMain.bas) を使用しています。データベースは SQLite で、データ バインディングを使用した ADO データ コントロールを介してアクセスします。コントロールには、MSFlexGrid、ListView、Toolbar、ImageList、およびコントロール アレイが含まれます。これを .NET 10 をターゲットとする ASP.NET Core Blazor Server アプリケーションに変換してください。 組織向けの移行パターンのカスタマイズ  移行の精度を向上させるために、組織固有のマッピングルールを提供します。これらはユーザーが作成したマークダウンファイルで、AWS Transform custom からプロンプトが表示された際に参照します。AWS Transform custom はこれらを変換プランに組み込みます。プロンプトが表示されたら、対話型セッション中に VB6 ソースコードとともにこれらのファイルを参照します。 図 2 – 変換プランへのビジネスルールやその他のコンテキストの追加 変換例の参照 <path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/example-transformations.md ファイルを確認します。ATX エージェントがサンプル変換を求めるプロンプトを表示したら、以下のように参照します。 変換前後の例は、<path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/example-transformations.md にあります。 企業コーディング規約の参照 AWS Transform custom では、組織のコーディング規約を変換に使用することでコード生成を制御できます。これには特定の C# の機能や規約を含めることができます。AWS Transform custom はこれらを使用して、チームのスタイルに合ったコードを生成します。<path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/coding-standards.md ファイルを確認します。組織のプラクティスに合わせて独自の規約を作成できます。 例 : <path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/coding-standards.md で定義されているコーディング規約を適用してください。 ターゲットアーキテクチャ仕様の参照 オプションとして、 <path-to-repository>/dotnet-genai-samples/src/Amazon.GenAI.TransformCustom/vb6-csharp-references/target-architecture.md にあるような、望ましい出力アーキテクチャを記述したドキュメントを使用できます。 AWS Transform custom は参照されたすべてのファイルを読み取り、組織のパターン、規約、アーキテクチャに合った変換プランを生成します。 生成された変換定義 あなたの入力に情報に基づいて、AWS Transform custom はフェーズごとに整理された包括的な変換定義を生成します。 フェーズ 1 – 分析 : VB6 コンポーネントのインベントリ、依存関係の特定、依存関係グラフの作成 フェーズ 2 – プロジェクト構造 : ASP.NET Core Blazor Server プロジェクトの生成、NuGet パッケージの設定、依存性注入のセットアップ フェーズ 3 – データレイヤー : ADO/DAO から Entity Framework Core への変換、DbContext とエンティティモデルの生成 (適切な場合は record 型を使用) フェーズ 4 – ビジネスロジック : モジュールからサービスクラスへの変換 (プライマリ コンストラクターを使用)、関数から async メソッドへの変換 フェーズ 5 – UI レイヤー : VB6 フォームから Blazor コンポーネントへの変換、イベントハンドラの変換 フェーズ 6 – 検証 : ビルド成功の確認、ユニットテストの生成、機能的等価性のテスト 変換定義をすぐに適用するか、レビューして修正するか、レジストリに公開して再利用するか、新しいプランを開始するかを選択できます。次のステップでは、大規模に再利用できるように変換定義を公開します。 AWS Transform custom は変換プランの名前と説明を提案してきます。そのまま受け入れるか、必要に応じて修正できます。これで変換定義がチーム全体で利用可能になります。 カスタム変換定義の表示と管理  公開後、対話型エージェントまたは以下の CLI コマンドを使用して、カスタム変換定義と利用可能なすべての AWS マネージド変換を表示できます。 atx custom def list 図 3 – ユーザーが作成したカスタム変換プランの一覧 このコマンドは、AWS マネージド変換 (AWS/ プレフィックス付き) とカスタム定義の変換の両方を表示します。カスタム定義の下に VB6-to-CSharp-Blazor-Migration 変換プランが表示されます。 ステップ 3: 変換を実行する カスタム変換定義を公開したら、VB6 アプリケーションのモダナイゼーションを実行できます。プロンプトが表示されたら、プロジェクトに対して変換プランを実行します。リポジトリへのパスと、変換後にプロジェクトをビルドするためのビルドコマンドを与える必要があります。 図 4 – 変換を検証するためのビルドコマンドの追加 以下のコマンドを使用して変換プランを直接ターミナルから実行することもできます。 atx custom def exec -p <path-to-repository>\  -n 'VB6-to-CSharp-Blazor-Migration' \  -t  AWS Transform custom が認識すべき追加のコンテキストを提供するかどうかを尋ねられます。これは、保存された変換定義には含まれないその場限りのコンテキスト (コード分析で生成されたドキュメントなど) を提供する場合に便利です。 図 5 – 変換プラン生成前の追加コンテキストの追加 プロンプトに回答すると、AWS Transform は実行またはレビュー・修正するための変換プランを生成します。 図 6 – 変換プランのレビューまたは続行 変換プランの内容に問題なければ 続行する 変換エージェントは SKS プロジェクトの構造を分析し、MDI コンテナ (frmMain.frm)、子フォーム、モジュール、データベースパターンを特定してから、変換定義を適用します。エージェントは以下を変換します。 frmMain.frm (MDI コンテナ) → ナビゲーションメニュー付きの Blazor MainLayout.razor frmCustomers.frm、frmProviders.frm など → 個別の Blazor ページコンポーネント modConnection.bas → Entity Framework Core と SQLite プロバイダーを使用した SksDbContext.cs modFunctions.bas → ドメインごとに整理された拡張メソッドクラス MSFlexGrid データグリッド → データバインディング付きの Blazor テーブルコンポーネント ADO データコントロール → async/await を使用した Entity Framework Core クエリ ステップ 4: レビュー、テスト、反復 変換が完了すると、AWS Transform custom は変換されたコードを新しいブランチまたはディレクトリに出力し、変換レポートと手動修正の次のステップを提示します。 変換結果のレビュー  変換レポートには、以下を含む終了基準の検証が含まれます。 dotnet build がエラーゼロで成功 すべての VB6 フォームが Blazor コンポーネントに変換済み (例: frmCustomers.frm → Customers.razor、frmOrderReception.frm → OrderReception.razor) データアクセスレイヤーが Entity Framework Core と SQLite プロバイダーおよび async パターンを使用 (ADO/ADODC データコントロールを置換) COM 依存関係の排除 — MSFlexGrid は Blazor テーブルコンポーネントに、Toolbar/ImageList は Blazor ナビゲーションに置換 エラーハンドリングが On Error 文から構造化された try-catch 例外処理に変換 仕様に従ったモダンな C# 機能の適用 (レコード型、プライマリコンストラクター、パターンマッチング) modConnection.bas が IDbContextFactory<SksDbContext> を使用した登録済み Dependency Injection (DI) サービスに変換 AWS Transform は 1 回の実行で検証基準を満たさない場合があります。変換の実行後、成功した部分と失敗した部分のサマリーを含む部分的な変換結果が得られることがあります。以下に変換結果を示します。 図 7 – 完了した変換結果 フィードバックプロンプトから、未達成の基準に対処するために変換を再実行できます。変換された SKS アプリケーションを検証するには、ターミナルに切り替えて以下を実行します。 cd <path-to-your-project>  dotnet build  dotnet run  ブラウザで https://localhost:<port> にアクセスし、以下に示すように Blazor アプリケーションが受注、顧客管理、商品カタログのページを正しくレンダリングすることを確認します。 図 8 – 請求書作成ページ 図 9 – 注文作成ページ 機能が不足している場合は、CLI にフィードバックを返して変換結果を繰り返し改善します。 Transform コマンドのパフォーマンス Transform custom コマンドは、変換対象のコードベースのサイズに応じて、完了までに最大 60 分かかる場合があります。コードファイルや依存関係が多い大規模なプロジェクトでは、当然ながらより多くの処理時間が必要になります。 変換の制限事項について Transform custom の機能では、VB6 アプリケーションのすべての機能を自動的に変換できるとは限りません。変換完了後、ソースの VB6 アプリケーションと変換先の C# アプリケーション間の機能を比較・検証する必要があります。変換されなかった不足機能については、 Kiro  や  Amazon Q Developer  などの AI 搭載ツールを使用して、ソースから変換先のコードベースへの変換・移植を支援できます。 ユニットテストの重要性 ユニットテストは、変換プロセス全体を通じて機能の正当性を検証します。変換されたコードが元の VB6 アプリケーションと同一の動作をすることを確認し、変換中に導入された不一致やリグレッションを迅速に特定するのに役立ちます。変換前に一連のテストを整備してください。これがリグレッションテストの基準となり、変換後も同等に動作することを検証できます。 まとめ 組織固有のパターン、ビジネスルール、モダンな C# 機能の設定を含むカスタム変換定義を使用することで、組織に蓄積された知見を維持しながら数百の VB6 アプリケーションを体系的にモダナイズできるようになりました。 変換を一度定義すれば、アプリケーションポートフォリオ全体に適用できます。これにより、再利用可能な変換定義に組織に蓄積された知見が保存されます。フィードバックループによる継続的な改善により、各変換はより洗練され、レコード型、プライマリコンストラクター、パターンマッチングなどのモダンな C# 機能がコードベースに自動的に適用されます。モダナイズされたアプリケーションは Linux と AWS Graviton 上で動作し、インフラストラクチャコストを削減できる可能性があります。 AWS Transform custom を使用して VB6 アプリケーションポートフォリオのモダナイゼーションを始めましょう。セットアップ手順については、 AWS Transform custom Getting Started Guide  をご覧ください。 追加リソース AWS Transform custom Getting Started Guide AWS Transform custom Product Page AWS Transform custom Documentation AWS Transform custom Command Reference AWS Transform for .NET .NET on AWS Developer Center 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について David Kilzer David Kilzer は、AWS エコシステム内での Microsoft ワークロードの最適化を専門とするソリューションアーキテクトです。C#、SQL Server、そして AWS サービスを用いた最新のソフトウェアソリューション構築に関する専門知識を有しています。 Ashish Bhatia Ashish Bhatia は、AWS のシニアソリューションアーキテクトで、エンタープライズのお客様のクラウドジャーニーのガイドに注力しています。AWS のクラウドネイティブサービスを使用して最新のソフトウェアソリューションを構築するお客様を支援することに情熱を注いでいます。また、彼は Amazon Web Services のスペシャリストソリューションアーキテクトです。最先端の生成 AI ソリューションの作成に取り組み、お客様中心のアプローチを優先しています。 Ty Augustine Ty Augustine は、.NET、SQL Server、コンテナを専門とする Microsoft スペシャリストソリューションアーキテクトです。ニューヨークを拠点に、様々な業界の企業と緊密に連携し、AWS クラウドへの移行とモダナイゼーションを加速させています。AWS に入社する前は、20 年以上にわたり Microsoft スタックのソフトウェアアーキテクトとして活躍していました。