この記事は、”Reimagine your mainframe applications with Agentic AI and AWS Transform” を翻訳したものです。 本ブログでは、reimagine パターンによってメインフレームのレガシーアプリケーションをモダナイズする AWS のアプローチの概要を説明し、組織がレガシー COBOL アプリケーションをモダンなクラウドネイティブアーキテクチャに変換する方法を紹介します。 人材不足、コスト増加、ビジネスアジリティの制約により、組織はレガシーメインフレームアプリケーションをモダナイズする喫緊の課題に直面しています。 AWS は、メインフレームアプリケーションをモダナイズするための複数のアプローチをサポートしています。Reimagine パターンにより、組織はカスタマーエクスペリエンスを再構想 (reimagine) し、ビジネスプロセスフローを最適化し、新機能を導入することで、モダンなアプリケーションに機能的な変化をもたらすことができます。このプロセスで、メインフレームアプリケーションをモダナイズすることができます。この過程は、モダンなアーキテクチャとテクノロジースタックを使った、アーキテクチャの再設計 (rearchitecting) と、アプリケーションのリライト (rewriting) を伴います。トランスフォーメーションジャーニーを加速させるため、エージェンティック AI を活用したツール一式によって、メインフレームのモダナイゼーションの reimagine パターンがサポートされています。 メインフレームアプリケーションを再構想するときの戦略的課題 AWS は、メインフレームモダナイゼーションの特効薬が無いことを認識しています。戦術的アプローチは既存システムの拡張と維持に重点を置いていますが、戦略的モダナイゼーションには リプラットフォーム (replatform)、リファクタリング (refactor)、リプレース (replace)、reimagine という明確な道筋があります。Reimagine は最も変革的なアプローチを代表しており、組織はマイクロサービスやバッチプロセスからリアルタイム機能への移行などのモダンなパターンを使って、アプリケーションアーキテクチャを全面的に見直します。 ほとんどのお客様は、reimagine 戦略を検討する際に 80:20 の原則に従います。Reimagine は、ビジネスでアプリケーションの機能強化が必要な場合に適しています。お客様は、メインフレームワークロードの一部だけがこのカテゴリに該当すると予想しています。このような状況では、モダンな UI、リアルタイム機能、またはより高速なバッチ処理が望まれている可能性があります。また、現行のモノリス化したアプリケーションをプロダクトに合わせたビジネス機能に分割したいという目標をお客様が持っている場合もあります。お客様は、自社のメインフレームアプリケーションの 20% が技術的な制約のせいでビジネスレベルの変更から真に恩恵を受けられない一方で、残り 80% は機能変更を必要としていないことに気付くかもしれません。ただし、一部の組織では、短期的な移行効率よりも長期的なビジネス変革を優先しており、パターンの選択は機能変更を必要とするアプリケーションの割合だけではなく、戦略的目標にも依存していることが実証されています。この洞察は AWS のマルチパターン戦略を推進する要素の 1 つです。AWS は複数の移行パターンをサポートしているので、お客様は各ワークロードに最適なモダナイゼーションアプローチを選択できるようになっています。 参考 5 AWS の reimagine 戦略の中心にあるのが AWS Transform for mainframe です。これは、エージェンティック AI を活用して、メインフレームアプリケーションのモダナイゼーションを加速するサービスです。このサービスにより、お客様は COBOL などの言語で記述されたモノリシックアプリケーションを、マイクロサービスのような、よりモダンなアーキテクチャスタイルに変換できます。AWS の reimagine 戦略の中心は、「Human in the Loop」原則に基づく検証です。この原則では、AI が生成したアプリケーション仕様とコードは、各分野の専門家によって継続的に検証される必要があります。AWS Transform for mainframe は強力なリバースエンジニアリングを提供し、Kiro はマイクロサービス仕様を生成します。ただし、プロセス全体を通して、人間の専門知識は依然として不可欠です。ビジネスロジックの解釈を検証し、アーキテクチャの境界を確認し、アプリケーションがすべての要件を満たしていることを検証するには、専門家が必要です。AI の機能と人間の判断によるこの協調的なアプローチは、AI を活用したモダナイゼーションのスピード上の利点を維持しながら、トランスフォーメーションのリスクを大幅に軽減します。 Strangler fig パターン: 進歩的なモダナイゼーションを可能にする手法 企業のお客様が、すべてのアプリケーションをメインフレームから同時に一括移行するようなビッグバンアプローチの大規模なモダナイゼーションを追求することはめったにないと認識されています。Strangler Fig アプリケーションパターンは、漸次的なモダナイゼーションの手法として実証済の選択肢です。このパターンは、トランスフォーメーション、共存、排除という 3 つの段階を経て、メインフレームアプリケーションをモダナイズするための安全なアプローチとなります。 Strangler fig パターンは、漸次的なモダナイゼーションアプローチです。これにより、組織は元のアプリケーションを実行したまま、モノリシックアプリケーションを徐々にマイクロサービスに置き換えることができます。このアプローチは、モノリスから機能を段階的に抽出することで機能します。抽出された機能は、既存のシステムを中心とした新しいマイクロサービスに変換されます。その後、統合パターンにより、新しいマイクロサービスとレガシーアプリケーションの間の接続が可能になります。 共存フェーズでは、メインフレームと AWS 上の新しいシステムの両方が同時に動作し、システム間の連携が行われます。連携パターンは、アプリケーション間の連携、アプリケーションからデータに対する連携、データ間の連携の 3 種類の統合をサポートします。 参考 4 このような連携アーキテクチャを構築し、共存に適した統合パターンを選択するには、お客様はハイブリッド環境全体におけるデータの一貫性、トランザクション管理、パフォーマンスに特に注意を払う必要があります。 メインフレームモダナイゼーションのためのマイクロサービスアーキテクチャの理解 マイクロサービスアーキテクチャーでは、従来のメインフレームのモノリシックなアーキテクチャーとは対照的に、システムを独立した小さなサービスに分割し、個別に開発、デプロイ、拡張できるようにすることを重視しています。メインフレームモダナイゼーションという文脈において、マイクロサービスには、明確なコンテキスト、独立したデプロイ、テクノロジーの多様性、スケーラビリティなど、重要な価値ある特徴があります。 マイクロサービスとイベント駆動型アーキテクチャを組み合わせると、バッチ処理からリアルタイム処理に移行する際に特に強力になり、変更に対してシステムが非同期で反応できるようになります。 マイクロサービスには大きなメリットがありますが、普遍的に最適なソリューションというわけではありません。データの一貫性やトランザクション性が必要な場合は、モジュラーモノリスやマクロサービスなどの代替アプローチの方が適している場合があります。重要なのは、現在のニーズと将来の願望の両方に適合するアーキテクチャを選択することです。 Reimagine パターンにおける 3 フェーズのモダナイゼーションアプローチ Reimagine パターンでは、3 フェーズの方法論を通じて、現行のメインフレームアプリケーションをクラウドネイティブなマイクロサービスに変換します。 リバースエンジニアリング : AWS Transform for mainframe を使用してリバースエンジニアリングを行い、既存の COBOL / JCL コードからビジネスロジックとルールを抽出します フォワードエンジニアリング : AI エージェント / Kiro を使ってマイクロサービス仕様とソースコードの両方を生成します デプロイとテスト : 生成されたマイクロサービスを Infrastructure as Code (IaC) を使って AWS にデプロイしてテストし、モダナイズしたアプリケーションの機能をテストします Reimagine パターンにおける 3 フェーズのモダナイゼーションアプローチ フェーズ 1: リバースエンジニアリング AWS Transform for mainframe を使ったリバースエンジニアリングのスコープを以下の図に示します。 AWS Transform を使ったリバースエンジニアリング モダナイゼーションを成功させるための基礎は、レガシーアプリケーションを深く理解することから始まります。AWS Transform は、メインフレームのソースコードと運用データ (スケジューラープラン、モニタリングデータ) など、複数のソースからの情報を組み合わせて分析します。このフェーズでは、次のような重要なアウトプットが得られます。 技術文書 : AWS Transform はソースコードを自動的に分析して、アプリケーションプログラムの詳細な文書を作成します。このドキュメントには、レガシーシステム内のプログラムロジック、フロー、連携、依存関係についての説明が含まれています。レガシーシステムに関する重要な知識を維持することで、退職するメインフレーム専門家への依存を減らすのに役立ちます。また、これまで分析や計画に費やされていたプロジェクト時間も短縮されます。 ビジネスロジックの抽出 : ビジネスロジックの抽出は、複雑なモノリシックアプリケーションをその構成要素であるビジネス機能に分解する、メインフレームのモダナイゼーションにおいて不可欠な機能です。AWS Transform は COBOL ソースコードを自動的に分析します。この分析は、レガシーアプリケーションに組み込まれているプロセスフローやビジネスロジックなど、重要なビジネス要素を特定して文書化するのに役立ちます。この分解プロセスは、モノリス化したメインフレームアプリケーションをより小さく、より管理しやすいビジネス機能に分解するための基本です。これらの機能は、reimagine の取り組みにおける後半の工程でマイクロサービスのスコープと境界を特定するための基礎となります。この機能は、技術ユーザーとビジネスユーザーの両方が理解できるエクスポート可能な自然言語で仕様を提供することで、モダナイゼーションの取り組みにおける複数のステークホルダーに役立ちます。 メインフレームデータモデル : AWS Transform には、データリネージ分析やデータディクショナリの自動生成など、メインフレームのモダナイゼーションを成功させるために不可欠な高度なデータ分析機能が備わっています。これらの機能が連携して、メインフレームデータの「場所」(使用法と関係) に付随する「内容」(構造と意味) を定義します。組織はデータ環境を完全に可視化できるようになり、情報に基づいたモダナイゼーションの意思決定が可能になります。技術チームは、重要なビジネスロジックとデータ間の関連性を維持しながら、自信を持ってデータアーキテクチャを再設計できます。 稼働分析 : システム管理機能 (SMF) を介してメインフレームから収集された実行時データによって、静的コード分析を補完することができます。SMF は z/OS サブシステム上のアクティビティデータを収集するための中心的なメカニズムです。これらの記録に含まれる情報は、モダナイゼーションの計画、優先順位付け、実行に不可欠です。AWS Transform は SMF データ (バッチ処理ではレコードタイプ 30、CICS トランザクションではレコードタイプ 110) を分析して、アクティブなバッチジョブと CICS トランザクションを識別できます。使用済み/未使用のトランザクション/バッチを検出し、トランザクション/バッチの MIPS 使用量を測定することで、組織は未使用のプログラムと消費量の多いリソースを特定できます。これにより、何を移行し、何を廃止するかについてデータ主導の意思決定が可能になり、メインフレームのリソース使用率をかつてないほど可視化できます。 フェーズ 2: フォワードエンジニアリング フォワードエンジニアリングは、抽出されたビジネスロジックをマクロサービス/マイクロサービスのアーキテクチャに変換することを目的としています。 AWS は、お客様組織内の多様なニーズを認識し、パートナー主導型およびお客様主導型の柔軟なコード生成アプローチを採用しています。AWS は、既存の開発者ツールと競合するのではなく、リバースエンジニアリングで得られた豊富な理解を 促進 することに重点を置いています。これにより、既存のコードを複数の方法でモダンなアプリケーションに正確に変換できるようになります。 Kiro やその他のコーディングアシスタントなどの好みの開発ツールを使用した、お客様主導またはパートナー主導の開発 AI を活用したコーディングアシスタントとしての Kiro や AI エージェントの活用 AWS Transform は Kiro のような AI を活用したコーディングアシスタントと連携して、仕様駆動型の開発をサポートします。これらのツールは互いに補完し合っています。AWS Transform が提供するアウトプットは、Kiro がマイクロサービス仕様とソースコードの両方を生成するためのインプットになります。 Kiro と AI エージェントのアプローチについて詳しく見ていきましょう。このアプローチは 3 つの異なるステップで構成されており、正しさと品質を Human in the Loop で 検証 します。 以下の図は、 Kiro または AI エージェントを使ったフォワードエンジニアリングのスコープを示しています。 Kiro / AI エージェントを使ったフォワードエンジニアリング ステップ 1: マイクロサービス仕様の生成 このステップでは、ビジネスロジックの抽出を入力として、AI エージェントまたは Kiro を使い、各マイクロサービスの詳細な仕様を作成します。Kiro の仕様駆動型のアプローチにより、アーキテクトはマイクロサービスを設計して正式な仕様を作成し、実装を開始する前に、アプリケーションの対象分野の専門家が各仕様を確認して改良することができます。プロジェクト固有のステアリング文書を作成することで、Kiro はインプット (ビジネスロジック、データ分析、非機能要件など) と要件についての理解を深めることができます。このステップでは、トレーサビリティとビジネスルールの包括的な適用範囲を検証する必要があります。これにより、特定されたすべてのビジネスロジックが適切に分析され、関連するマイクロサービス仕様に組み込まれたかどうかを追跡できます。 Kiro にマイクロサービス仕様の生成を依頼するステアリングファイルのサンプルを次に示します。 マイクロサービス仕様を生成するためのステアリングファイルのサンプル 【参考】日本語訳 ## Role: あなたはソフトウェア設計、特にドメイン駆動設計、マイクロサービスアーキテクチャ、システムモダナイゼーションの分野で 20 年以上の経験を持つシニアソフトウェアアーキテクトです。エンタープライズアプリケーションのモノリスからマイクロサービスへのトランスフォーメーションを何十回も成功させてきました。あなたは、境界コンテキストの特定、クリーンなドメインモデルの設計、効果的なサービス境界の構築に関する専門家です。ソフトウェア設計パターン、API 設計、イベント駆動型アーキテクチャ、フロントエンド統合戦略に関する深い知識を有します。 ## Action: … `input/bre_output` フォルダーとサブフォルダー内の提供された HTML ファイルと JSON ファイルを分析して、現在のビジネスロジック、データ構造、および暗黙的なドメインモデルを理解してください。追加のコンテキストが必要な場合のみ、`input/source-code` フォルダーとサブフォルダーのソースコードを参照してください。 `input/bre_output` フォルダーとサブフォルダー内の HTML ファイルと JSON ファイルにあるビジネスロジックに基づいて、主要なビジネスドメイン、サブドメイン、潜在的な境界コンテキストを特定します。追加のコンテキストが必要な場合のみ、`input/source-code` フォルダーとサブフォルダーのソースコードを参照してください。 ドメイン駆動設計の原則を適用して、独自のユビキタス言語、集合ルート、エンティティ、バリューオブジェクト、ドメインイベントを使用して明確な境界のあるコンテキストを定義します。 特定された境界コンテキストに基づいてマイクロサービスアーキテクチャを設計し、各マイクロサービスが単一の責務を担い、独自のデータを管理するようにします。 ステップ 2: ターゲットデータベースの生成 データベースのモダナイゼーションは、メインフレームトランスフォーメーションプロジェクトにおける極めて重要な課題です。レガシーメインフレームデータベースは、IMS/DB や IDMS などの階層型データベースやネットワーク型データベース、または Db2 などのリレーショナルデータベースを使って構成されています。これらのデータベースには、ビジネス上の重要なデータが何十年にもわたって蓄積されていますが、今となっては時代遅れのデータモデルに従って構造化されているものもあります。ターゲットデータベースの生成フェーズでは、これらのレガシーデータ構造を、データの整合性とビジネスルールを維持しながらマイクロサービスアーキテクチャをサポートするモダンなクラウドネイティブなデータベーススキーマに変換します。AWS Transform のデータ分析機能により、レガシーデータベース構造を包括的に理解できます。Kiro は、このデータ分析結果をターゲットアプリケーションの仕様と組み合わせてインプットとして使用し、ターゲットのモダナイズされたデータベースを作成します。 ステップ 3: ソースコード生成と Infrastructure as Code の生成 仕様を検証した後、Kiro は実装フェーズに移行し、本番環境ですぐに使えるマイクロサービスコードと Infrastructure as Code を生成します。実装プロセスは、要件定義、設計、実装タスクという Kiro の 3 フェーズのワークフローに従います。このフェーズでは、Kiro は実装タスクを自律的に実行できます。一方、開発者は生成されたコードのレビュー、フィードバックの提供、要件に対する実装の検証に集中できます。このプロセスにはステアリングファイルが不可欠です。これによって Kiro はプロジェクトの規約、ライブラリ、標準に関する永続的な知識を得ることができ、確立されたアーキテクチャガイドラインやコーディング標準に準拠することができます。この構造化されたアプローチにより、チームは実装戦略を見直し、改良することができます。また、品質保証活動のための包括的なテストケースとテストデータの生成にも役立ちます。 Kiro にマイクロサービスのターゲットソースコードの生成を依頼するステアリングファイルのサンプルを次に示します。 ターゲットソースコードの生成のためのステアリングファイルの例 【参考】日本語訳 ## Action: まず microservices-specs フォルダーから提供されたマイクロサービス仕様を分析し、必要な各マイクロサービス、その責務、データモデル、連携ポイントを特定します。 以下を含む customer-management-service マイクロサービスシステムの全体的なアーキテクチャを設計します。 サービスの境界と責任 データの所有権と共有のアプローチ 通信パターン (同期 vs 非同期) 各コンポーネントの AWS サービスの選択 仕様書に記載されている customer-service マイクロサービスの場合: 適切な Maven/Gradle 構成で Spring Boot プロジェクト構造を作成する データモデルフォルダの下にある顧客の DynamoDB テーブル定義をマッピングするデータモデルを実装する REST のベストプラクティスに従って RESTful API コントローラーを開発する サービス層のビジネスロジックを指定どおりに実装する 適切な例外処理、検証、ロギングを追加する AWS サービスインテグレーション (必要に応じて DynamoDB、SQS、SNS など) を設定する サービスのユニットテストを書く 以下は、マイクロサービスを実装するためのプロンプトとステアリングファイルから Kiro によって生成されたタスクファイルのサンプルです。 マイクロサービスを実装するタスクファイルの例 【参考】日本語訳 [x] 1. 顧客管理サービスのプロジェクト構造を設定する Maven のディレクトリ構成で Spring Boot プロジェクトを作成する マルチモジュールプロジェクト構造 (domain, application, infrastructure, web) を設定する さまざまな環境 (dev, staging, prod) に合わせてアプリケーションプロパティを設定する 重要な依存関係 (Spring Boot, Spring Data, AWS SDK, validation, testing) を追加する _要件: 1.1、2.1_ [x] 2. コアドメインモデルとバリューオブジェクトを実装する [x] 2.1 ドメインロジックによる顧客集約ルートを作成する すべての必須フィールドとビジネスメソッドを含む Customer エンティティを実装する バージョンフィールドによるオプティミスティックロックを追加する ドメイン検証ルールを実装する _必要条件:5.1、5.5_ [x] 2.2 データの一貫性を実現するためのバリューオブジェクトを実装する ID が 9 文字であることのチェックも含めて CustomerID バリューオブジェクトを実装する フォーマット検証と暗号化をサポートする SSN バリューオブジェクトを作成する 電話番号のフォーマット (XXX-XXX-XXXX) のチェックを含む PhoneNumber バリューオブジェクトを作成する 値の範囲が 300 ～ 850 になるチェックを含む FICoScore バリューオブジェクトを作成する _必要条件:5.3_ フェーズ 3: デプロイとテスト 最後のフェーズでは、生成されたマイクロサービスを、さまざまなコンピューティングオプションとストレージオプションを使用して AWS クラウドネイティブアーキテクチャにデプロイします。お客様は、コンピューティングサービスとして Amazon Elastic Container Service (ECS)、Amazon Elastic Kubernetes Service (EKS)、AWS Lambda、AWS Fargate の中から選択できます。データベースオプションには、NoSQL ワークロード用の Amazon DynamoDB、リレーショナルデータベース用の Amazon Aurora、またはその他の AWS データベースサービスが含まれます。デプロイでは、AWS CloudFormation、AWS Cloud Development Kit (CDK)、Terraform などの Infrastructure as Code ツールを使って AWS リソースのモデル化とプロビジョニングを行います。 以下は、AWS CloudFormation テンプレートを使って新しいマイクロサービスアーキテクチャを AWS クラウドにデプロイするように生成された Infrastructure as Code のサンプルです。 生成された Infrastructure-as-Code の例 再構想 (reimagine) された新しいアプリケーションは、この新しい AWS クラウドネイティブアーキテクチャでテストされ、すべてのコンポーネントが期待どおりに動作することを検証します。 以下の図は、新しく作り直されたアプリケーションをデプロイするための一般的な AWS クラウドネイティブアーキテクチャを示しています。 新しく reimagine されたアプリケーションのデプロイとテスト Reimagine パターンのための AI 駆動アプローチの主な利点 ディスカバリーと分析の加速 AWS Transform の AI エージェントは、複雑な COBOL コードベースを数時間または数日で分析し、アプリケーションドメインとビジネスロジックパターンを自動的に識別できます。組織はメインフレーム環境全体を分析するか、もしくは、特定のビジネスプロセスを対象として分析するか、選択することができます。 インテリジェントなマイクロサービス設計 AI を活用したアプローチでは、ドメイン駆動設計 (Domain-Driven Design: DDD) の原則を適用して、レガシーアプリケーション内の自然な境界のあるコンテキストを識別します。DDD は、中核となるビジネスドメインの理解、技術チームとビジネスチームの間に共通のユビキタス言語の構築、複雑なドメインを明確に境界付けられたコンテキストに分割することに重点を置いています。 高品質なコード生成 Kiro は、適切な階層型アーキテクチャ、REST API 設計、クラウドネイティブパターンなど、最新の開発標準に従った、本番環境に対応したマイクロサービスを生成します。 Infrastructure as Code このアプローチでは、アプリケーションコードと、マイクロサービスを AWS クラウドにデプロイして実行するために必要なインフラストラクチャ全体の両方が生成されます。さらに、この Infrastructure as Code アプローチは AWS Well-Architected Framework の原則に沿ったものであり、自動化され繰り返し可能なデプロイによって運用上の卓越性を促進し、生成されたすべてのインフラストラクチャコンポーネントにセキュリティ、信頼性、パフォーマンス効率、コスト最適化、ベストプラクティスを一貫して適用できるようにしています。 AWS メインフレームモダナイゼーションの専門知識とパートナーエコシステム メインフレームアプリケーションを reimagine するための AWS のアプローチは、AWS の AI 駆動の機能を活用し、パートナーの専門知識とスケールを補完するものです。AWS は、Global System Integrators (GSI) と専門技術パートナーの専門知識を組み合わせて、メインフレームモダナイゼーションプロジェクトに内在する複雑さに対処する強固なパートナーエコシステムを構築しました。 GSI パートナーは、さまざまな業界の大規模なメインフレームモダナイゼーションで成功を収めていることが実証済です。 AWS の戦略は、データ移行ユーティリティ、テストフレームワーク、言語変換ツールなどの AWS ネイティブ機能を補完する専用のモダナイゼーションツールを提供するテクノロジーパートナーに依存しています。 このような協業アプローチにより、お客様は AWS のクラウドネイティブ機能を活用しながら、複雑なモダナイゼーションの課題に対応する専門知識と実証済の方法論を活用できます。 まとめ AWS がメインフレームモダナイゼーションを再構想 (reimagine) するために進めているのは、お客様のトランスフォーメーションジャーニーを加速させる包括的な AI 駆動のアプローチです。AWS Transform は、レガシーソースコードに対する深い理解と柔軟なコード生成を組み合わせることで、組織がリスクを最小限に抑え、ビジネス価値を最大化しながらメインフレームアプリケーションを変革できるようにします。 メインフレーム向けの AWS Transform と Kiro に関するその他の参考情報 インタラクティブデモを試す AWS Transform for mainframe の詳細 入門ガイドを読む メインフレームから AWS への移行途中の過渡期に於ける両環境併存のための連携アーキテクチャ メインフレームアプリケーションのモダナイゼーションに関する包括的な視点と配置戦略 著者 Yann Kindelberger Yann Kindelberger は、Amazon Web Services の Principal Solution Architect です。Yann は 23 年以上メインフレームに携わり、IBM で 20 年以上メインフレームアーキテクトとして勤務しました。彼はメインフレームの AWS クラウドへの移行とモダナイゼーションに取り組んでいるワールドワイドなチームの一員です。彼は 2021 年に AWS に入社し、ソリューションアーキテクトとして、お客様のメインフレームの移行とモダナイゼーションを支援し、助言し、サポートしています。 Cheryl du Preez Cheryl du Preez は、メインフレームとレガシーモダナイゼーションに関する AWS の World Wide Senior Specialist Solutions Architect です。Cheryl は、世界中のお客様を対象としたメインフレームのモダナイゼーションとトランスフォーメーションの取り組みにおいて、20 年以上にわたって技術的リーダーシップを発揮してきました。現在の役職では、AWS 独自の方法で生成 AI を活用したメインフレームのモダナイゼーションについて、お客様やパートナーに対して助言を提供しています。 Chris Poole Chris は Senior Partner Solutions Architect であり、メインフレームモダナイゼーションが大好きです! 彼は現在、EMEA 地域の AWS メインフレームパートナー戦略を推進していますが、以前はエッジコンピューティングテクノロジーに取り組む Principal Engineer の称号を持っていました。当時は、コミュニティや開発者支援の取り組みをリードし、クラウドセキュリティ製品のソリューションアーキテクトチームを率いたり、高スループットの金融取引処理システムにおける非同期 API を設計/開発したりしてきました。彼は理論物理学の博士号を取得しています。余暇には、香取神道流の武道やカリ (Kali) 等の格闘技を楽しんでいます。 Rao Panchomarthi グローバルのメインフレームモダナイゼーション組織のリーダー。Rao は、IBM メインフレーム、分散システム、クラウドテクノロジーにまたがる 20 年以上の経験を持つ経験豊富な IT プロフェッショナルです。Rao は大規模なビジネストランスフォーメーションをリードし、メインフレームアプリケーションのクラウドテクノロジーへの移行や、モダナイズするための戦略を策定しています。AWS に入社する前は、JPMorgan Chase のクレジットカード事業でアーキテクチャ責任者を務め、複数のトランスフォーメーションプロジェクトをリードしていました。 Souma Suvra Ghosh Souma は AWS でメインフレームモダナイゼーションを担当する Senior Specialist Solutions Architect です。AWS へのモダナイゼーションに関する複数の記事やソリューションガイドを発表し、AWS re:Invent や AWS Summit などのカンファレンスで発表を行ってきました。現在の役職では、メインフレームとレガシーシステムのモダナイゼーションに AWS のバリュープロポジションと生成 AI 機能を最大限に活用する方法について、お客様やパートナーに助言しています。 Subhajit Maitra Subhajit は AWS の Worldwide Mainframe Partner Solution Architect であり、メインフレームモダナイゼーションコンピテンシープログラムの構築を支援しました。また、IBM MQ 連携に寄与する AWS Mainframe Modernization サービスのビルダーでもあります。彼の専門分野には、メインフレームモダナイゼーション、メッセージ指向ミドルウェア、分散型イベントストリーミングプラットフォーム、マイクロサービスなどがあります。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 8 月 4 日（火）に、半導体業界向けのイベント EDA on the Cloud 2026 – Tokyo を AWS 麻布台オフィスで開催します。EDA ワークロードのクラウド活用に加えて、Cadence AI Super Agent による設計・検証フローや、Anthropic Japan による「半導体のためのフロンティア AI」など、AI 関連のセッションが揃っています。ソニーセミコンダクタソリューションズ株式会社様による「ソニー半導体 EDA 基盤の Cloud Journey」の講演も予定されています。定員 100 名、参加費無料です。ご興味のある方はお早めにご登録ください。 それでは、7 月 20 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース 寄稿：弁護士ドットコムにおける AWS DevOps Agent の活用事例 – インシデント対応の自動化と属人化の解消 弁護士ドットコム株式会社 様は、法律相談ポータル「弁護士ドットコム」や電子契約サービス「クラウドサイン」を運営する企業です。サービスの拡大とともにアラートが増える一方、調査は一部の熟練エンジニアに依存していました。これを解決するために、Datadog Monitor のアラートを起点に AWS DevOps Agent が自動で調査を始める構成を組み、Skills と Jira の MCP で起票までつなげました。その結果、あるレイテンシ障害では、従来 30 分ほどかかっていた根本原因の特定を約 10 分で終えています。今後は、繰り返すアラートへの予防策を提案する Proactive Incident Prevention の活用を本格化させるそうです。 ブログ記事「9 社合同 AI-DLC Unicorn Gym：AI と作った 2 日間で見えた、「書く」から「決める」への転換」を公開 9 社 11 チーム・約 90 名が自社の実課題を持ち込み、 Kiro と Claude Code で AI 駆動開発ライフサイクル（AI-DLC）を 2 日間走り切った合同ワークショップのレポートです。「Kiro は 1 ヶ月と見積もった。私たちは 2 日で 80% 終わった」という声の一方で、生成物の正しさを判断し続ける負荷が人間に集中したという指摘も率直に載っています。満足度は 4.7/5.0、体感の工数削減率は平均 74.0%。クロージングの一言「Don’t write code, Write construct.（コードを書くな、構造を作れ）」に、2 日間の学びが凝縮されています。 ブログ記事「22社51名の参加者が2時間で業務アプリを自作し発表 ！Claude ・Kiro実践ワークショップの記録」を公開 22 社 51 名が 2 時間のハンズオンで自分の業務課題を題材にアプリを作り、その場で発表したワークショップの記録です。日本曹達株式会社様の広報課の方が、過去の問い合わせ回答を検索できる農業化学品 FAQ アプリを作られた例が取り上げられています。「このアプリを作ってください」というお題をあえて出さない設計が、満足度 100% につながったようです。社内で同じような会を企画される方のヒントになりそうです。 ブログ記事「【開催報告】AWS Summit Japan 2026 – AWS for Telcom 展示ブース」を公開 通信業界向けの 7 ブースをまとめた開催報告です。株式会社NTTドコモ様は AWS 上の 5G コアを国内初のハイブリッドクラウド構成で商用化し、 Amazon Bedrock AgentCore 上のエージェントと GitOps による構築自動化でリードタイムを 80% 短縮されました。100 万台超の機器を扱うネットワーク保守 AI エージェントでは、障害復旧時間を 50% 以上縮めています。KDDI株式会社様は基地局制御基盤の内製開発に AI-DLC を導入して開発期間を 70% 削減、ソフトバンク株式会社様は Amazon Neptune でネットワークトポロジーを時系列管理する様子を展示されました。 ブログ記事「スマートグラス × 音声 AI エージェントで実現する店舗業務のハンズフリー支援」を公開 「あの商品どこ？」に新人スタッフが即答できない、という店舗の困りごとをスマートグラスと音声 AI エージェントで解く展示の解説記事です。音声をそのまま受けて音声で返す Amazon Nova 2 Sonic がモデル内で Tool Use まで済ませ、Amazon Bedrock AgentCore Gateway に登録した 5 つの Lambda を MCP 経由で呼び出します。自店舗に在庫がなければ近隣店舗や EC まで自律的に探しにいく挙動が読みどころです。手が塞がる現場での情報アクセスという課題は、製造や物流にもそのまま当てはまります。 ブログ記事「【開催報告】AWS Summit Japan 2026 — 物流異常を Amazon Quick が自動解決：配送在庫の異常検知〜問合せまで一気通貫」を公開 複数システムにデータが散らばり、日次レポートの目視確認で異常発見が数日遅れる。そんな物流現場の課題に Amazon Quick で応える展示の紹介です。Quick Automate が業務システムを横断監視して Microsoft Teams へ通知し、Quick Sight で滞留状況を確認、Chat Agent が基幹データと過去報告書をまたいで原因を掘り、Connectors で業者へのメール送信まで完結します。半日かかっていた原因追及が数分になる流れを、4 ステップで追えます。 ブログ記事「AWS Japan Summit 2026 スマートマシンデモ ー自律診断とリアルタイム安全監視ー 展示報告」を公開 建設機械 20 台のフリート管理を題材に、同じデータへの 3 つの異常検知アプローチを並べて比べた展示報告です。人手による報告、 Amazon SageMaker AI の古典的な機械学習、そして Amazon Bedrock AgentCore と Strands Agents によるエージェント型。「異常スコアは出るが、なぜ起きたのか、何をすべきかは分からない」という機械学習の限界に対して、対処指示まで含むアラートを返せる差が具体例つきで示されます。機械を止める判断は人間に残す、という線引きの考え方も参考になります。 ブログ記事「AWS Summit Japan 2026 に見る Resilience at AWS」を公開 レジリエンス関連のセッション 4 本とブース展示 6 本のまとめです。生成 AI 視点では、AI 駆動カオスエンジニアリング、AWS DevOps Agent による「調査は AI、判断は人」のインシデント対応、Kiro と AWS Resilience Hub を組み合わせて、マルチリージョン化の提案レポートから CloudFormation テンプレートの改修まで生成するデモが目を引きます。ナレッジを整えたことで DevOps Agent の根本原因到達が 6 分 32 秒から 3 分 38 秒に縮んだ、という実測値も載っています。 ブログ記事「【開催報告】Neuron Community – 2026 Vol.1」を公開 AWS Trainium / Inferentia と AWS Neuron の知見を共有するコミュニティイベントの開催報告です。カラクリ株式会社様は、Amazon EKS 上の Neuron 分散学習プラットフォームと、NKI カーネル開発を自律的に進めるエージェントを発表されました。AWS 側からは、デバイス指定を変えるだけで PyTorch のコードを Trainium で動かせる Native PyTorch support（ベータ）や vLLM on Trainium、Neuron 2.31 の NKI 強化が共有されています。Project Rainier では 140 万個超の Trainium が稼働中とのことです。 ブログ記事「AI エージェントが変える AWS 運用の未来【AWS DevOps Agent & AWS サポート ランチタイムセミナー開催レポート】」を公開 「深夜にアラートが鳴っても調査する人手が足りない」というスタートアップの悩みに向けたランチタイムセミナーのレポートです。Amazon ECS の 500 エラーを題材にした AWS DevOps Agent のデモに加えて、一次調査はエージェント、判断が必要なところは AWS サポートの専門エンジニアへ、という組み合わせ方が解説されています。DevOps Agent からサポートチケットを直接起票できる点と、AWS Business Support+ や AWS Activate クレジットといったコスト面の選択肢も整理されています。 ブログ記事「今月の AWS オブザーバビリティ – 2026年6月」を公開 6 月に発表された Amazon CloudWatch と AI 駆動型オペレーションの新機能のまとめです。OpenTelemetry メトリクスと PromQL クエリの一般提供、Logs Insights への 23 コマンド追加、AWS DevOps Agent のカスタム SRE エージェントと MCP / A2A 対応などが並びます。Amazon EKS 上の AI/ML ワークロードを namespace やチーム単位で GPU コスト配賦するリファレンスアーキテクチャ、Claude Code のトークン消費量を追跡するパターンまでカバーしています。 ブログ記事「AWS Certified Machine Learning Engineer – Associate アップデート (MLA-C02) のお知らせ」を公開 AWS Certified Machine Learning Engineer – Associate が MLA-C02 に更新されます。ドメイン構成は変えずに、基盤モデルのファインチューニングや RAG アーキテクチャの実装、エージェンティック AI、 Amazon Bedrock のカバレッジ、責任ある AI の実践が加わります。ベータ版試験（英語のみ、170 分、85 問、75 USD）の予約は 9 月 1 日開始、現行 MLA-C01 の英語での最終受験日は 9 月 28 日です。日本語はベータ期間中も MLA-C01 で受験でき、全言語対応の標準版は 2027 年初頭の予定です。 ブログ記事「Claude Opus 5 が Kiro で利用可能になりました」を公開 （ changelog ） Kiro の IDE / CLI / Web すべてで Claude Opus 5 が使えるようになりました。時間のかかる作業に強くなり、並列で動かしたエージェントが互いの成果を上書きしてしまうケースが減っています。スタブやプレースホルダを残さずタスクを完走する点、コードレビューで誤検知を抑えつつ実バグを拾う点が Opus 4.8 からの差分です。あわせて、 Kiro で GPT-5.6 が利用可能に なった記事（前号で触れた英語版の日本語訳）も出ています。 サービスアップデート Claude Opus 5 が AWS で利用可能に Anthropic の Claude Opus 5 が AWS で利用可能になりました。数時間から夜通し動き続けるエージェント、コードベースを理解しながら戦略を組み替えるコーディング、長文ドキュメントの推論が強みです。ドキュメント中心の業務で最も伸びが大きいと説明されています。Amazon Bedrock 経由（ゼロデータ保持がデフォルト有効）と Claude Platform on AWS 経由（ゼロデータ保持はリクエストベース）の 2 つから選べます。 Amazon Bedrock AgentCore がトレースとログを単一ロググループにまとめた統合オブザーバビリティを提供 Amazon Bedrock AgentCore が、トレース・プロンプト・構造化ログ・標準出力をエージェントごとの単一の CloudWatch ロググループへ配信するようになりました。これまではトレースが共有の aws/spans、イベントログが別のロググループに分かれており、1 回の呼び出しをデバッグするために複数のロググループを探す必要がありました。エージェント単位で IAM ポリシーとカスタマー管理キーによる暗号化を適用できるようにもなっています。7 月 20 日以降に作ったエージェントはデフォルトで有効、既存分は環境変数と ADOT 0.17.1 以降への更新で移行できます。 Claude Sonnet 5 が AWS GovCloud (US) の Amazon Bedrock で利用可能に AWS GovCloud (US) の Amazon Bedrock でも Claude Sonnet 5 が使えるようになりました。Claude Opus 4.8 とあわせて、GovCloud (US-West / US-East) の bedrock-runtime と、GovCloud (US-West) の次世代推論エンジン bedrock-mantle の両エンドポイントから呼び出せます。 Amazon SageMaker AI 推論の GPU インスタンスが拡充、G7e が東京リージョンでも利用可能に NVIDIA RTX PRO 6000 Blackwell を最大 8 基積む G7e インスタンスが、Amazon SageMaker AI 推論のアジアパシフィック（東京 / ソウル）、欧州（ロンドン）に広がりました。合計最大 768 GB の GPU メモリで、FP8 なら最大 70B パラメータのモデルをマルチノードなしで載せられます。推論性能は G6e 比で最大 2.3 倍。国内のユーザーに大きめのモデルを低レイテンシーで届けたいときの選択肢になります。同じ週に G7 インスタンス （米国 3 リージョン、G6 比で最大 4.6 倍、7B〜30B 向け）と G6 の AWS GovCloud (US-East) 対応 も発表されています。 Amazon SageMaker Unified Studio が Amazon OpenSearch をサポート Amazon SageMaker Unified Studio が Amazon OpenSearch をデータソースとして扱えるようになりました。プロジェクトに接続を追加すると data explorer に OpenSearch のデータが並び、クエリエディタやノートブック、ビジュアル ETL ジョブから Amazon Redshift や Amazon S3 のデータと突き合わせられます。アプリケーションログとトランザクションデータを、ツールを行き来せずに見たいときに便利です。Unified Studio が使えるすべてのリージョンが対象です。 Kiro IDE 1.0.182 と CLI 2.14.0 が公開 Kiro IDE 1.0.182 では、ユーザーレベルのグローバル hooks と検索できるセッション履歴パネルが加わり、企業プロキシ環境での安定性が上がりました。応答が中断したときの自動復帰と、MCP ツールの動的な再読み込みにも対応しています。CLI 2.14.0 では、V2 のカスタムエージェント設定を V2 / V3 共通の形式へ移す /upgrade-agent コマンドが入りました。 Kiro が AWS GovCloud (US) で Opus 4.8 / Sonnet 5 とユーザーアクティビティモニタリングに対応 AWS GovCloud (US) の Kiro IDE / CLI で、Claude Opus 4.8（1M コンテキスト、クレジット倍率 2.2 倍）と Claude Sonnet 5（実験的サポート、同 1.3 倍）が使えるようになりました。あわせて管理者向けに、利用状況ダッシュボードと、クレジットやモデル利用の日次 CSV を自分の S3 バケットへ配信するレポート、任意のプロンプトログが提供されます。データは自社アカウントに残り、S3 のストレージ以外の追加料金はかかりません。 Amazon CloudWatch がコーディングエージェントインサイトを発表 Amazon CloudWatch に、AI コーディングエージェントの利用状況を可視化するコーディングエージェントインサイトが加わりました。Claude apps gateway for AWS と統合されているため、計装なしで Claude Code のテレメトリが集まります。Codex や GitHub Copilot も対象です。トークン支出の傾向を追ってアラートを設定できます。エージェントの導入率とコミットやプルリクエストの速度との相関、費用対効果の高いモデルの見極めにも使えます。中東（UAE / バーレーン）とイスラエル（テルアビブ）以外のすべての商用リージョンで使えます。 AWS Data Exports が Amazon Bedrock の標準化された製品メタデータを提供 AWS Data Exports が、Amazon Bedrock のコストにモデルプロバイダー、モデル名、料金単位、推論タイプ、オンデマンドやバッチといった機能区分を、標準化された属性として付けるようになりました。Bedrock のコストは統一の「Amazon Bedrock」製品ファミリー名にまとまります。CUR 2.0 のメタデータを解析する自作ロジックなしで支出を配賦できます。追加料金なしで、デフォルトで適用されます。 AWS が AI エージェント向けのオープンソースベンチマーク aws-bench を発表 AI エージェントが実際の AWS タスクをどれだけ正確に、どれだけ効率よく片づけられるかを測るオープンソースのベンチマーク aws-bench が、リサーチプレビューで公開されました。テストケースは調査・トラブルシューティング・インフラ作成の 3 領域。自然言語のクエリ、クラウドリソースの状態、正解を組にしてあるので、任意のエージェントやモデルを同じ基準で採点できます。エージェントの実行基盤を自作している方は、改善の物差しとして試してみてはいかがでしょうか。 Amazon Connect のエージェンティック音声が 50 以上の言語に対応、日本語もサポート Amazon Connect のエージェンティック音声が、日本語を含む 50 以上の言語と 100 を超える音声オプションに対応しました。不自然な間を埋める応答ペーシング、同時発話を避けるターンテイキングの改善、速度・音量・感情の制御も入っています。日本語で自然な音声セルフサービスを組みたいコンタクトセンターには、大きな一歩です。 AWS パートナーセントラルのエージェントが資金調達ガイダンスをすべてのプログラムに拡大 AWS パートナーセントラルのエージェントが、すべての資金調達プログラムに対応しました。今回の拡張で戦略的協業契約（SCA）と AWS Growth Initiative（AGI）が加わっています。資格要件や申請プロセスについては、公式ドキュメントに基づく回答が数秒で返ります。適格性の検証、提出書類の要件照合、必要項目が埋まった申請書ドラフトの作成もエージェントが行うため、手入力とチェック漏れを減らせます。 生成 AI を活用したビジネス課題の解決に取り組むお客様を支援する AWS ジャパン生成 AI 実用化推進プログラム は、通年で応募を受け付けています。戦略プランニング / モデルカスタマイズ / モデル活用の 3 コースから選べて、想定コストの半額を上限とした AWS クレジットの付与や技術支援も用意されていますので、ぜひご検討ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。 a

はじめに こちらの記事 で実際にKubernetes環境にKubeBlocksを導入し、DBaaSの基盤を構築しました。 前回の記事 ではKubeBlocksを利用してDBaaS基盤上にMySQLを構築しました。 今回は、KubeBlocksを利用してNoSQLのインメモリデータベースであるRedisを構築していきます。 導入環境構成図 以下の図は、DBaaS基盤上にRedisを導入する環境の構成図です。 「KubeBlocksオペレーター」は こちらの記事 で構築しました。 本記事では、赤丸で囲まれた「DB(Redis)」の構築を対象とします。 Redisはすべてのデータをメモリ上で処理する「インメモリデータベース」の一種で、NoSQLに分類されます。 ディスク（SSD/HDD）にアクセスする一般的なデータベースと比較して圧倒的に高速なのが特徴で、主にWebサイトやアプリの高速化（キャッシュ）や、リアルタイム処理に利用されるDBになります。 導入環境構成図 Redisの構築方法 KubeBlocksを使用してRedisを構築する手順をご紹介します。 今回は最もシンプルな、1台のサーバーでRedisを稼働させるスタンドアロン構成で作成していきます。 前提条件 KubeBlocksが構築済みであること KubeBlocksによってデフォルトでインストールされるRedisアドオン（以下コマンド結果のredis 1.0.1）が有効になっていること 以下のkbcliコマンドで有効化されているアドオンを確認することができます。 kbcli addon list # 出力例 NAME VERSION PROVIDER STATUS AUTO-INSTALL qdrant 1.0.1 community Disabled false rabbitmq 1.0.1 community Disabled false apecloud-mysql 1.0.1 community Enabled true etcd 1.0.1 community Enabled true kafka 1.0.1 community Enabled true mongodb 1.0.1 community Enabled true mysql 1.0.1 community Enabled true postgresql 1.0.1 community Enabled true redis 1.0.1 community Enabled true Namespeaceの作成 まずはRedisをデプロイするNamespeaceを作成します。 kubectl create namespace redis # 出力例 namespace/redis created デフォルトユーザー認証用Secretの作成 Redisのデフォルトユーザー用のユーザー名・パスワードを設定したSecretを作成します。 kubectl create secret generic custom-redis-root-secret \ --from-literal=username='default' \ --from-literal=password='<任意の値>' \ -n redis # 出力例 secret/custom-redis-root-secret created ※Redis作成時に本手順で作成したSecretを指定することで、デフォルトユーザーのパスワードを任意の値で設定することができます。 Secretの指定がない場合は、KubeBlocksがデフォルトユーザー用のパスワードを自動発行します。 Redisの作成 MySQLクラスター構築時と同様に、KubeBlocksのカスタムリソースである「Cluster」のマニフェストを適用し、Redisを作成します。 cat <<EOF | kubectl apply -f - apiVersion: apps.kubeblocks.io/v1 kind: Cluster metadata: name: redis-cluster namespace: redis spec: terminationPolicy: Delete clusterDef: redis topology: standalone componentSpecs: - name: redis replicas: 1 systemAccounts: - name: default secretRef: name: custom-redis-root-secret namespace: redis serviceVersion: 8.0.3 disableExporter: false resources: limits: cpu: "0.5" memory: "0.5Gi" requests: cpu: "0.5" memory: "0.5Gi" volumeClaimTemplates: - name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi EOF # 出力例 cluster.apps.kubeblocks.io/mycluster created clusterDef: redis Redisアドオンが提供するRedisの構成テンプレートを、作成するDBクラスターのベースとして指定する設定です。 topology: standalone Redisを単一のRedisサーバーインスタンスで構成されるスタンドアロンクラスターとして起動する設定です。 terminationPolicy: Delete クラスターを削除した際、関連するデータも一緒に削除する設定です。 systemAccounts Redisのデフォルトユーザーの認証情報（ユーザー名・パスワード）に、事前に作成したSecretを割り当てる設定です。 volumeClaimTemplates DBのデータを保存するためのPVの設定です。 Redisの作成確認 Redis作成コマンド実行後、以下のコマンドでクラスター・Podのステータスを確認します。ステータスがRunningになっていれば正常に動作しています。 kubectl get cluster redis-cluster -n redis # 出力例 NAME CLUSTER-DEFINITION TERMINATION-POLICY STATUS AGE redis-cluster redis Delete Running 110s kubectl get pods -n redis # 出力例 NAME READY STATUS RESTARTS AGE redis-cluster-redis-0 4/4 Running 0 2m15s 動作確認 Redisへの接続テストを行います。 まず、作成したRedisのエンドポイント（Service名）を確認します。 kubectl get svc -l app.kubernetes.io/instance=redis-cluster -n redis # 出力例 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE redis-cluster-redis-redis ClusterIP 10.43.163.160 <none> 6379/TCP 3m kubectl runコマンドでRedisクライアント用のPodを作成し、コンテナ内でシェルを起動します。 kubectl run redis-client -n redis --rm -i --tty --image=redis:8.0.3 --restart=Never -- bash # 出力例 If you don't see a command prompt, try pressing enter. root@redis-client:/data# redis-clientコマンドを使用し、確認したRedisのエンドポイント、「 デフォルトユーザー認証用Secretの作成 」で作成したユーザ名・パスワードを指定して接続します。 root@redis-client:/data# redis-cli -h redis-cluster-redis-redis.redis.svc.cluster.local -p 6379 --user default --pass xxxxx # 出力例 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. redis-cluster-redis-redis.redis.svc.cluster.local:6379> Redisに正常に接続できているか、以下のPINGコマンドを使用して確認します。 redis-cluster-redis-redis.redis.svc.cluster.local:6379> PING # 出力例 PONG 「PONG」が出力されれば、正常に接続できています。 続いて、データの登録・取得が行えるかを確認します。 キー「test」に値「”Hello World” 」を登録します。 redis-cluster-redis-redis.redis.svc.cluster.local:6379> SET test "Hello World" # 出力例 OK 登録したデータが正しく取得できるかを確認します。 redis-cluster-redis-redis.redis.svc.cluster.local:6379> GET test # 出力例 "Hello World" 登録した「”Hello World” 」という文字列が出力されれば、Redisへのデータ登録と取得は正常に行えています。 これでRedisの構築と動作確認は完了になります。 おわりに 前々回構築したKubeBlocksを使用し、実際にRedisの構築から接続テストを行うまでの流れをご紹介しました。 前回のMySQL構築に引き続き、容易にRedisを構築できることを体感できたのではないでしょうか 。 今回は最もシンプルな「Redisサーバ1台のスタンドアロン構成」として構築しましたが、KubeBlocksなら本番環境向けの冗長構成も、マニフェストの設定を少し変更するだけで簡単に構築することができます。 KubeBlocksは様々なDBをサポートしているため、他のDBも同様の方法で手軽に導入することができます。 本記事が、Kubernetes上でDBを構築する際の選択肢として、KubeBlocksを検討するきっかけになれば幸いです。 参考文献 https://kubeblocks.io/docs/preview/kubeblocks-for-redis/03-topologies/01-standlone https://kubeblocks.io/docs/preview/kubeblocks-for-redis/06-custom-secret/01-custom-secret ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post KubeBlocksでRedisを導入！Kubernetes上での高速キャッシュ/NoSQL構築を体験 first appeared on SIOS Tech Lab .