Amazon Web Services ブログ

Zocdoc は AWS で TensorFlow を使用し患者の信頼を築きます

ヘルスケア産業は複雑です。近年の調査では、半数以上のアメリカ人は、保険の取扱い範囲を理解するのが困難だと感じており、4 分の 3 のアメリカ人は医者が保険ネットワーク内にいるかどうかをもっと容易に確認する方法を望んでいます。 Zocdoc は、患者がこの迷路の中で行く方向を明らかにしていき、医療を受ける必要のある人に、より多くの情報に基づいた選択肢を与え、ニーズに合わせたケアを見つけることができるようにする上で役立ちます。AWS の深層学習は、Zocdoc の使命の核心部分にあり、患者を支援するために医療データを最適化するものです。TensorFlow の深層学習フレームワークを使用して構築されたアルゴリズムにより、Zocdoc は患者と医師をより効率的に照合します。全国平均では、新しい患者の待ち時間が平均 24 日であるのに対し、患者は 24 時間以内に予約を取ることができます。 「当社は、ヘルスケア分野で消費者に対応する企業として、患者のエクスペリエンスを改善するために、データ指向のイノベーションをもたらそうという熱意をもっています。当社の検索プロセスでは、複数のアルゴリズムを使用して患者の意図を解析し、患者のニーズを適切な専門家と照合させています」と Zocdoc の CTO Serkan Kutan は述べています。 深層学習による検索エクスペリエンス Zocdoc の Insurance Checker では、患者は健康保険カードの写真を撮ることのみが必要です。このシステムは、深層学習をベースにしたコンピュータービジョンを使用して ID カードをスキャンし、正しいポリシー ID 情報を抽出します。Zocdoc のエンジニアリングチームとデータサイエンスチームは、さまざまな種類の ID カードを解読するのが困難であるという課題に直面しましたが、AWS のクラウドベースの GPU サーバーを使用して、わずか 1 日でニューラルネットワークの PoC(実証支援)を作成することができました。 Insurance Checker は、会員 ID 情報を抽出した後、患者の健康保険付保範囲をリアルタイムで確認し、ネットワーク内の保険給付と、予測される自己負担金を確認します。 患者が自分の健康保険付保範囲を理解している場合でも、何週間も予約待ちをしている患者と、より速く予約が取れる意思の間でのミスマッチが起こることがよくあります。Zocdoc は、患者を適切でネットワーク内の予約可能な医師と照合する、機械学習をベースにしたデジタルのヘルスマーケットプレイスを提供します。 Zocdoc のデータサイエンスダイレクター、Brian D’Alessandro は次のように述べています。「当社では、深層学習を利用して、保険カードの画像を保険会社とプランに分類し、主要テキストフィールドを抽出して読み込み、患者が付保範囲を把握し、最も適切な医者を見つける支援をしています。」 詳しい背景情報 Zocdoc は、その識別と照合システムのために TensorFlow […]

Read More

Amazon Comprehend を使用したカスタマーレビューからのセンチメントの検知

今日の社会では、パブリックコンテンツがこれまでにない重要性を持っています。カスタマーレビューからのデータは、それに関連するセンチメントの理解がビジネスに貴重な市場認識と早期かつ積極的に問題に取り組む能力を提供することから、消費関連の意思決定に対する洞察を得るためのツールとして使われています。 センチメント分析は、文書が肯定的、否定的、中立的、または混合的のどれであるかを計算によって判断するプロセスを使用します。Amazon Comprehend は、自然言語処理 (NLP) テキスト分析サービスで、キーフレーズ、挙げられた組織名、および言語と併せてセンチメントを検知し、ドキュメントコレクションからトピックモデリングを実行することを可能にするいくつかの API で構成されています。センチメントを検知するこのサービスの機能は、テキストの評価時にスコア付けのメカニズムと属性を使用する最先端のディープラーニングアルゴリズムを用いて行われます。Amazon Comprehend トレーニングデータセットは、世界で最も大規模な自然言語コレクションのひとつである Amazon.com からの製品説明と消費者レビューにあるデータを中心に構成されています。AWS は、言語の進化に遅れを取らないために新しいデータでの再訓練が継続的に行われる完全に訓練されたモデルを提供します。一般の機械学習では、大半のデータエンジニアと開発者に対して現在持っているものとは異なるスキルセットが求められます。Amazon Comprehend はこのギャップを取り除き、開発者がすでに持っているスキルを使って簡単に NLP を実行できるようにしました。 このブログ記事では、カスタマーセンチメントを検知するために、AWS のサービスを使って構築されたサーバーレスイベント駆動型アーキテクチャの一部として Amazon Comprehend を活用する方法を説明します。 ソリューションのアーキテクチャ概要 Amazon.com の製品レビューを取り上げて、一定のレビューのセンチメントを分類するために Amazon Comprehend を使ってみましょう。Amazon Echo、Amazon Echo Dot、および Amazon Echo Show のレビューを例として使用します。次に、ブランドを損なわないようにするために追加の架空サンプルデータをアップロードし、リコールされている欠陥、破損、または危険アイテムといったニュアンスを持つ否定的な製品センチメントの取得をシミュレートします。最後に、Amazon Athena を使用して否定的なレビューに対するインタラクティブなクエリを行い、レポートをエクスポートすることによって、ビジネスが即座に対策を講じられるようにします。 レビューのアップロード: ユーザーは、カスタマーレビューをテキスト形式でカスタマーレビューバケットにアップロードします。  カスタマーレビューセンチメント分析関数: セキュアなレビューのアップロードが、レビューを一時ファイルにダウンロードし、それに対するテキスト分析を実行するように Amazon Comprehend を呼び出してから、肯定的、否定的、中立的、または賛否混合的な信頼スコアと共に全体的なセンチメントを CSV ファイルに出力するレビューセンチメント分析関数をトリガーする Amazon S3 イベントとして使用されます。センチメントが出力された CSV ファイルは、同じカスタマーレビューバケットのセンチメントフォルダに保存されます。 インタラクティブな SQL クエリ: Amazon […]

Read More

チャットボットにウェブ UI をデプロイする

お客様は、Amazon Lex をお使いになり非常に優れたチャットボットを構築しました。Amazon Lex コンソールをご使用になりチャットボットをテストしました。これでチャットボットを皆様のウェブサイトにデプロイ出来るようになります。 お客様が独自のボットユーザーインターフェース (UI) を構築することは可能ですが、荷が重いと感じられるかもしれません。様々なデバイスとブラウザに対するサポート、承認、音声録音などを扱う必要があります。以前に既に実行されているはずだと考え、上手く再使用できるソリューションが見つかるかもしれません。 Amazon Lex チャットボット UI チャットボット UI と呼ばれる Amazon Lex ウェブ UI のサンプルは、 Amazon Lex チヤットボットにフル機能のウェブクライアントを提供する関連する重要部分にすでに対応しています。この機能を迅速に活用して時間を最小限に抑えることで、お使いになられているチャットボットを搭載したアプリケーションの価値を見出すことができます。 フルページのチヤットボット UIとして稼働させることができます。: あるいは、チャットボットウィジェットとしてサイトに組み込むこともできます。: チャットボット UI は、以下の機能をサポートしています。: フルスクリーンまたは組み込み可能なウィジェットモードを備えた、モバイルに対応する UI 音声とテキストを完全にサポートし、二者間をシームレスに切り替えることができる 自動消音検出、トランスクリプション、オーディオの録音および再生、Amazon Lex レスポンスの再生を中断する機能などの音声機能 テキストと音声の両方をサポートするレスポンスカード ホスティングサイトからチャットボット UI とプログラムを介して対話する機能 複数のデプロイメントのオプション デプロイメントと統合のオプション チャットボット UI のデプロイメントと統合には4つのオプションがあります。 AWS CloudFormation の使用 AWS Mobile Hub の使用 事前に構築されている配布ライブラリの使用 事前にパッケージ化された Vue コンポーネントの使用 […]

Read More

AWS Deep Learning AMI に TensorFlow 1.5 と新しい Model Serving 機能が追加されました

AWS Deep Learning AMI は、機械学習を迅速かつ簡単に開始する支援となります。AMI には、機械学習の実践者の多様なニーズに応えるさまざまなプレビルドのオプションが含まれています。ディープラーニングのフレームワークの最新バージョンをご希望の方には、Deep Learning AMI は、別々の Conda ベースの仮想環境にインストールされたプレビルドのピップバイナリを提供します。高度なフレームワーク機能をテストしたり、フレームワークのソースコードを調整したりするのをお求めの方のために、ソースコード付きの Deep Learning AMI では、ソースからフレームワークのカスタムインストールを提供します。これらはしばしば、ストックバイナリでは利用できない高度な最適化でビルドされます。 Volta GPU での TensorFlow によるより速いトレーニング ソースコード付き AMI には、TensorFlow 1.5.0-rc1 が付属します。このプレリリースバージョンの TensorFlow は、EC2 P3 インスタンスに電力を供給する V100 Volta GPU を利用する NVidia CUDA 9 および cuDNN 7 ドライバをサポートします。当社のテストでは、ResNet-50 ベンチマークを合成 ImageNet データで fp-16 モードで p3.8xlarge インスタンスでトレーニングすると、TensorFlow 1.4.1 でのトレーニングよりも 1.8 倍高速になりました。これはプレリリースバージョンであるため、本番環境で使用する前にテストしてください。 Ubuntu と Amazon Linux […]

Read More

AWS DeepLens Lambda 関数と最新 Model Optimizer を深く知り尽くす

AWS DeepLens 向けに最新 Model Optimizer をリリースしました。これは皆さんのディープラーニングモデルを DeepLens GPU 上で効率的に実行できるよう最適化するもので、Python のコード一行のみで実行可能です。Model Optimizer は AWS DeepLens ソフトウェアバージョン 1.2.0 で利用できます。 AWS DeepLens は推論のために GPU にアクセスする際、Cl-DNN (Compute Library for Deep Neural Networks) を使用します。そのため、AWS DeepLens 上でモデルを実行するには、Cl-DNN 形式に変換しなくてはなりません。Model Optimizer はモデルのサイズにもよりますが、次のコード 1 行で、この変換を実行します。所要時間は 2-10 秒間です。 mo.optimize(model_name,input_width,input_height) このコードを自身の Lambda 関数に含めることで、Model Optimizer にアクセスできるようになります。Lambda 推論関数を使用することにより、AWS DeepLens からデプロイしたばかりのモデルにアクセスできるようになります。この投稿では、Lambda 推論関数の作成方法について説明するとともに、皆さんの要件に合わせてカスタマイズできるテンプレートをご紹介します。 Lambda の推論はプリプロセス、推論、ポストプロセスの 3 つの関数を実行します。 Lambda 推論関数を作成するには、AWS Lambda コンソールを使用し、以下のステップに従ってください […]

Read More

水門は開いた – EC2 インスタンスのネットワーク帯域幅が増大

2016 年の中頃、Elastic Network Adapter (ENA) を使用するために AMI と現世代の EC2 インスタンスを構成するようお勧めしましたが、皆さんはきちんと宿題をこなしましたか。ENA の特徴は高スループット低レーテンシであること、その一方でホストプロセッサの負荷を最小限に留めることなどが挙げられます。複数の vCPU 環境で適切に機能するようデザインされ、複数の送信および受信キューを使ってインテリジェントにパケットのルーティングを行います。 今日、私たちは水門を開けて (帯域幅の制限を取り払って)、すべての AWS リーションでより多くの帯域幅をご利用いただけるようになりました。仕様は以下のとおりです (それぞれの事例で実際の帯域幅はインスタンスのタイプとサイズによって異なります): EC2 – S3 間 – Amazon Simple Storage Service (S3) との送受信通信量は、帯域幅で最大 25 Gbps ご利用いただけます。これまで、この通信量の帯域幅は上限が 5 Gbps に設定されていました。これは S3 にある大規模なデータにアクセスする、またはバックアップおよびリストアに S3 を使用するアプリケーションに有益です。 EC2 – EC2 間 – 同一リージョン内で、同一または異なるアベイラビリティーゾーンにある EC2 同士の通信では、ここで解説したようにプライベート IPv4 または IPv6 アドレスを使用することにより、シングルフロー通信の場合最大 5 Gbps、マルチフロー通信の場合最大 25 Gbps […]

Read More

ユニシスメインフレームからAWSへの5ステップでの移行

この記事はAstadia社のレガシーモダナイゼーションサービスのバイスプレジデントである Craig Marbleによるものです。 ユニシスメインフレームをお持ちの場合は、あなたはビジネスのバックボーンとして機能している信頼性の高いプラットフォームとアプリケーションポートフォリオの構築に投資していると思います。しかし、今日の技術環境は、ユニシス、メインフレームが提供できるよりも低コストで、より柔軟性と俊敏性を必要としています。 Amazon Web Services(AWS)のコンサルティングパートナーであるAstadiaでは、ユニシスメインフレームのアプリケーションワークロードを実行するための現代的で柔軟性のある選択としてAWSを利用しており、ユニシスメインフレームのアプリケーションとデータへの過去の投資を活用していることがわかりました。 慎重に計画、管理、実行すると、ユニシスメインフレームワークロードをAWSに移行することの利点は数多くあります。 Pay-as-you-goモデルのコスト削減に加えて、ユニシスメインフレームアプリケーションセットがAWSに完全に移行されると、実証済みのビジネスロジックを最新のテクノロジーと統合して、データ分析やモバイル対応を可能にし、新しい市場、顧客、パートナーにビジネスを拡大します。これを念頭に置いて、ユニシスメインフレームアプリケーションをクラウドに移行することは、贅沢と言うより必要にせまられてということのようです。 この記事では、ユニシスメインフレームアプリケーションをAWSに移行するのに役立つ5つのステップを紹介します。 元のアプリケーションのソースコードとデータを再利用し、最新のAWSサービスに移行することをお勧めします。 ユニシスメインフレームの移行を可能にするツールは、既存のコードをそのまま維持することができますが、一部のコンポーネントを置き換えてデータストレージを再考する必要があります。 このような最小限の変更のアプローチは、手作業の書き換えやパッケージの置き換えに比べてプロジェクトのコストとリスクを削減し、20年または30年の投資を活用しながら新しい市場を活用するための新技術との統合のメリットを享受します。ひとたび移行されると、アプリケーションは、既存のスタッフが現代化を進めるのに十分な特性をもつようになります。また価値ある知識野蓄積を新しいデベロッパーに伝えています。 ステップ1:ディスカバー まず、環境内のすべてのアプリケーション、言語、データベース、ネットワーク、プラットフォーム、およびプロセスをカタログ化して分析する必要があります。アプリケーション間のとすべての連携ポイントと、外部連携ポイントを文書化します。できるだけ多くの自動分析を使用し、すべてを一元的なリポジトリにまとめます。 Astadiaは、Micro Focus Enterprise Analyzerなどの商用分析ツールと独自に開発したパーサーを組み合わせて、従来のコードを迅速かつ効率的に分析します。この分析出力は、Astadia Code変換エンジンに供給される移行ルールを確立するために使用されます。これらのルールは、プロジェクト全体を通じて更新され、洗練されます。 ステップ2:デザイン すべてのソースコード、データ構造、および最終形の要件を分析した後、ソリューション設計をするときが来ました。設計には、以下の詳細を含める必要があります。 AWSインスタンスの詳細:インスタンスタイプについて言うと、汎用Tインスタンスは、開発、テスト、または統合環境に向いていますが、汎用Mインスタンスは本番環境、本番前環境、およびパフォーマンスが要求される環境に向いています。 トランザクション負荷:一般的な非機能要件ですが、1秒あたりのトランザクション数が多いなどのパフォーマンス要件、または迅速な応答時間は、メインフレームのワークロードの実行にとって重要な場合が多いです。このことはネットワーク、ストレージ、コンピューティングの設計とサイズ設定を慎重に行う必要があるということです。 バッチ要件:バッチアプリを動かすほとんどすべてのユニシスメインフレームは、通常I/O集約型で、ストレージやデータストアからのレイテンシーが非常に短い事が要求されます。これは分散システムの課題であるため、バッチインフラストラクチャは早期に設計してテストする必要があります。 プログラミング言語の変換と置換:移行対象先でサポートされていない言語や使用できない言語は、ツールで変換したり、新しい機能に置き換えることができます。 外部システムとの統合:ユニシスメインフレームは、一般的にサテライトやパートナーシステムのバックエンドまたは記録システム(SOR)であり、移行後にはプロトコル、インターフェイス、レイテンシー、帯域幅などの統合を維持する必要があります。 サードパーティのソフトウェア要件:各ISV(Independent Software Vendor)はAWS上で機能的に同等のソフトウェアを利用できる場合もあれば、そうでない場合もあるため、特定の移行パスの定義が必要です。 将来要件の計画:ビジネス、IT戦略、優先順位は、特に将来のパフォーマンスと統合機能に関わるため、アーキテクチャの決定を左右します。 ソースコードには、Sperry MAPPER、Burroughs LINC、COBOL、またはECLが含まれます。データストアには、DMS(ネットワーク接続)、DMSII(階層型)、またはRDMS(リレーショナル型)が含まれます。 このデザインがUnisys ClearPath Libraマッピングを探す方法は次のとおりです。 図2 – Unisys Libra(Burroughs)メインフレーム移行アーキテクチャのコアコンポーネントは、レガシーコードを実行するための一連のエミュレータとユーティリティを使用するメインフレームクラウドフレームワークです。   同様のマッピングは、TIP、MASM、BIS(Mapper)、ECLを含むUnisys ClearPath Doradoシステムでも実行できます。 図2のアーキテクチャのコアコンポーネントは、レガシーコードを実行するための一連のエミュレータとユーティリティを使用するメインフレームクラウドフレームワークです。 OpenMCSは、移行されたコードをサポートするUnisys COMSの必要なトランザクション処理機能を提供するAstadiaのメッセージ制御システムです。このメインフレームクラウドフレームワークは、コンピュートリソースとしてAmazon Elastic Compute Cloud(Amazon EC2)上で動作します。 ほとんどの場合、ユニシスメインフレームの階層型およびフラットファイルのデータ構造は、Amazon Relational Database Service(Amazon […]

Read More

【開催報告】Gaming Tech Night #2 re:Born(再始動)

こんにちは。ゲームソリューションアーキテクトの吉田です。 昨日1/24(水)に第2回となるGaming Tech Nightを開催し、多くのゲーム開発者、インフラエンジニアの方々にご参加いただきました。Gaming Tech Nightは過去2016年に開催された、ゲームに特化した技術情報をお届けすることを目的としたAWS主催のイベントでしたが、今年からは定期開催イベントとして新しく生まれ変わりました。記念すべき再開1回目となる今回は、re:Born(再始動)というタイトルでサーバレスやCI/CDなど複数のテーマで計4セッションをお届けしました。   サーバレスアーキテクチャ入門 ~ Game Server Services 丹羽様 Game Server Services株式会社 代表取締役社長CEOの丹羽様より、サーバレスアーキテクチャについてご講演いただきました。入門というタイトルですが、サーバレスの定義から実装に関する注意点、実際に丹羽様が構築・運用する中で習得されたノウハウなどが詰まった内容の濃いセッションでした。これからサーバレスをはじめる方だけでなく、すでに構築・運用されている方々にも非常に参考になるポイントが多かったのではないかと思います。登壇資料はGS2 Blogで公開されています。   AWSにおけるモバイルゲーム向けAPIサーバの実装2018 ~ ソリューションアーキテクト 畑 ソリューションアーキテクトの畑より、モバイルゲームを対象としたAWSにおけるAPIサーバ実装について解説しました。典型的な実装パターンである3層Webアプリケーションパターンをはじめ、API Gateway+Lambda+DynamoDBを利用したサーバーレスアーキテクチャ、アプリケーション上で実装されたAWS SDKを通じて各AWSサービスのAPIに直接アクセスする2-Tierアーキテクチャなどの実装ポイントをご紹介しました。また、現在Public Preview中であるAWS AppSyncによる実装パターンにも触れました。API用のクエリ言語であるGraphQLは、クライアント〜サーバ間で共有される型が利用できたり、クライアント側からサーバのレスポンスデータの形式を指定できたりとモバイルゲームでも応用できる多くの利点があります。AWS AppSyncはマネージドなGraphQLのサービスであり、ゲーム開発者の方にもインフラを意識することなくご利用いただけます。ぜひPreviewにご参加ください。 Serverless backendformobilegame and_aws-appsync_gamingtechnight-2 from Amazon Web Services Japan   AWS上で実現するゲーム開発CI/CDパイプライン ~ ソリューションアーキテクト 森 ソリューションアーキテクトの森からは、AWSのCode系サービスを利用したゲーム開発におけるCI/CDパイプラインの実装例の解説とデモを披露しました。ソースコードをCodeCommitにpushし、CodeBuildによるビルド、CodeDeployによるステージング環境へのデプロイ、そしてステージングでのテスト完了後に再度CodeDeployを使って本番環境にという一連の流れをCodePipelineを自動化することが可能です。特にコードのビルドについては、ビルド用で常にインスタンスを確保されているお客様も多いと思いますが、CodeBuildはビルド実行時間のみの課金となりますので、コストが削減できるケースも多いと思います。ぜひゲーム開発のCI/CDにおいてもAWSのマネージドサービスをご活用ください。 Gaming cicd-pipeline gaming-technight-2 from Amazon Web Services Japan   AWSを最大限活用したロングヒット戦略 ~ Amazon […]

Read More

AWS Glue がScala をサポートしました

私たちは、AWS Glue の ETL(Extract、Transform、Load)を実行するためのスクリプトにおけるScalaのサポートを発表することに興奮しています。Scala が好きな人達は強力な武器を1つ手に入れることになり喜んでくれるでしょう。AWS Glue では Apache Spark をデータ加工のエンジンとして使用していますが、Scala は Apache Spark のネイティブな言語です。 洗練された言語としての機能が使える以外にも、Glue のスクリプトをScala で書くことはPython で書くことに比べて2つの利点があります。まずは、Python とApache Spark のScala ランタイム(JVM)の間でデータを移す必要がないので、Scala は大量のデータ移動を伴う加工整形処理がより高速です。サードパーティのライブラリで独自の変換を作成したり関数を呼び出すことができます。 次に、Scala はJava と互換性があるように設計されているため、外部Java クラスライブラリの関数をScala から呼び出すことが簡単です。 そのため、Scala のコンパイル結果は Java と同じバイトコードになりますしデータ構造を変換する必要もありません。 これらの利点を説明するために、GitHubアーカイブから入手可能なGitHub パブリックタイムラインの最近のサンプルを分析する例を説明します。このサイトはGitHubサービスへのパブリックリクエストのアーカイブで、コミットとフォークから、イシューとコメントまで35種類以上のイベントタイプを記録しています。 この記事は、タイムラインのネガティブなイシューを特定するScala スクリプト作成の方法を紹介します。このスクリプトではタイムラインサンプルのイシュー イベントを引き出し、Stanford CoreNLPライブラリのセンチメント推定機能を使用してタイトルを分析し、最もネガティブなイシューを浮き彫りにしています。 入門 スクリプトを作成する前に、AWS Glue Crawler を使ってデータ構造と特性を理解します。また、開発エンドポイントとZeppelin ノートブックをセットアップすることで、データをインタラクティブに探索してスクリプトを作成することもできます。 データをクロールする この例で使われているデータセットは、GitHub アーカイブからAmazon S3 のサンプルデータセットバケットにダウンロードされています。場所は以下の通りです: s3://aws-glue-datasets-<region>/examples/scala-blog/githubarchive/data/ <region>をあなたの作業中のリージョンに置き換えて最適なフォルダを選択してください。例えばap-northeast-1 などです。AWS Glue Developer Guide […]

Read More

高い可用性を持つ IBM Db2 データベースをAWS上に構築する

多くのAWSのお客様がミッションクリティカルなワークロードをIBM Db2データベースプラットフォームを利用して実行しています。一般的に、こういったワークロードには、ノード障害やデータセンターサイトの障害時でも運用を続けられる高い可用性が必要とされます。 従来のIBMソフトウェアにおける高可用性手法は、共有ディスクと仮想IPアドレスを使用し、これをTivoli System Automation for Multi-Platforms (TSAMP)でコントロールするというものでした。このブログポストでは ネイティブのIBMとAWSの技術を用い、かつ自動化された手法を説明します。これによりミッションクリティカルなDb2ワークロードをAWS上で稼働でき、高可用性のDb2データベースを安心して提供できるようになります。 注:このガイドで使用するIBM Db2は、フル機能が90日間利用できるトライアル版のDb2 for Linux, Unix and Microsoft Windows バージョン11です。トライアル期間が終了したあとは、必要とするエディションを選択、購入し、ライセンスファイルを導入して利用することが可能です。このガイドで利用している機能が使用できるエディションは、Db2 Advanced Enterprise Server Edition、 Db2 Enterprise Server Edition、Db2 Advanced Workgroup Server Edition、Db2 Workgroup Server Editionです。より詳細な情報はIBM Webサイトを確認してください。(訳注:こちらにエディションの違いの詳細があります) この記事のステップを進めていくと、2つのアベイラビリティゾーン(AZ)にまたがって高可用性を実現するDb2 データベースを作成します。データはAZ1にあるプライマリーインスタンスとAZ2にあるスタンバイインスタンスの間でHADR(High Availability Disaster Recovery)機能でレプリケーションされます。もしプライマリーノードが利用できなくなった場合、TSAMPがそれを検知し、スタンバイインスタンスにフェイルオーバーさせます。Db2 クライアントアプリケーションは自動クライアントリルート機能 (IBM Automatic Client Reroute : ACR)により自動的に新しくプライマリーになったインスタンスに再接続されます。 事前準備のステップ このソリューションはAWSのデフォルトVPC (Virtual Private Cloud)にデプロイされます。デフォルトVPCはAWSアカウント作成時に自動的に各リージョンに作成されています。もしデフォルトVPCが無い場合は、次のステップに進む前に以下を実行してください。 同一リージョンの2つのパブリックサブネットを持つVPCを作成してください。それぞれのサブネットは別のAZに配置してください。 VPCにインターネットゲートウェイを配置してください。それぞれのサブネットはインターネットゲートウェイ経由でインターネットに出られるようにします。 最初にAmazon S3 […]

Read More