Author: Danilo Poccia

 Amazon DynamoDB などの NoSQL データベースを使用する場合、リレーショナルデータベースで慣れているものとは異なる最適化を選択する傾向があります。リレーショナルデータベースの経験から、最初は別の方法で実行するように指示されていたため、簡単ではありませんでした。 これを支援するために、AWS は Windows および macOS で利用可能なクライアント側アプリケーションである Amazon DynamoDB 向け NoSQL Workbench をリリースしました。これを使用して、スケーラブルで高性能なデータモデルを構築し、クエリの開発とテストを簡素化できます。NoSQL Workbench を使用すると、次のことができます。 1 つ以上のテーブルを使用してデータモデルを定義します。 データモデルを視覚化して、さまざまなシナリオでどのように機能するかを理解します。 複数のプログラミング言語用のデータプレーン操作を構築します。 このブログ記事では、一般的に利用可能になった NoSQL Workbench を使用して、複数の顧客の URL ブックマークの管理という一般的なユースケースのデータモデルを設計しています。比較的ユースケースが単純な場合でも、多くの興味深い考慮事項があります。 データモデラー このアプリケーションでは、ブックマークと顧客アカウントに関する情報を保存する必要があります。まず、保存したい属性のリストを、保存する予定の簡単な説明とともに書き留めます。 顧客 customerId – ユニバーサル一意識別子 (UUID) email fullName ­– 例: “Shirley Rodriguez” userPreferences – アプリのユーザー設定を記述する JSON オブジェクト creationDate updateDate ブックマーク URL – “https://…” customerId […]

 昨年の re:Invent で、Amazon Managed Apache Cassandra Service (MCS) のプレビュー版を紹介しました。過去数か月の間に、このサービスは多くの新機能を導入し、今日 Amazon Keyspaces (Apache Cassandra 用) という新しい名前で一般公開します。 Amazon Keyspaces は Apache Cassandra 上に構築されており、フルマネージドのサーバーレスデータベースとしてご利用いただけます。アプリケーションは、既存の Cassandra Query Language (CQL) コードを使用して、まったくまたはほとんど手を加えずに Amazon Keyspaces からデータを読み書きできます。各テーブルでは、以下のように、ユースケースに応じて最適な設定を選択できます。 オンデマンドでは、実際に行った読み取りと書き込みに基づいて料金が発生します。これは、ワークロードが予測できないときに最適なオプションです。 プロビジョニングされた容量では、容量設定を事前に行うことで、予測できるワークロードのコストを削減できます。 また、Auto Scaling を有効にすることで、コストをさらに最適化できます。これにより、その日のトラフィックの変化に応じてプロビジョニングされた容量設定が自動的に更新されます。 Amazon Keyspaces の使用 私が子供の頃に構築した最初の「本格的な」アプリケーションの 1 つは、本用のアーカイブでした。それを今すぐ、以下を使用してサーバーレス API として再構築したいと思います。 データを保存するための Amazon Keyspaces。 ビジネスロジック用の AWS Lambda。 Amazon API Gateway と新しい HTTP API。 Amazon […]

 今日は、待ちに待った新しい AWS リージョンがイタリアで利用可能になったことをお知らせしたいと思います! 欧州 (ミラノ) リージョンは欧州 6 番目の AWS リージョンで、信頼性に優れた方法で複数のデータセンターにアプリケーションを分散させるため (たとえば、Amazon Elastic Compute Cloud (EC2) インスタンスに異なる AZ を使用するよう Amazon Virtual Private Cloud のサブネットを設定するなど) に使用できる 3 つのアベイラビリティーゾーン (AZ) で構成されています。 各 AZ は、AWS のインフラストラクチャの完全に隔離されたパーティションで、1 つ、または複数のデータセンターが含まれます。 AZ は分離された個別の地理的地域に設置されており、単一のイベントがリージョンの可用性に影響するリスクを大幅に減らすために十分な距離が置かれていますが、迅速なフェイルオーバーおよび同期レプリケーションを必要とするビジネス継続性には十分な近さです。これは、単一のデータセンターで実現できるものよりも、可用性、耐障害性、およびスケーラビリティに優れた本番アプリケーションを運用する能力を提供します。Amazon Simple Storage Service (S3)、AWS Lambda、および Amazon DynamoDB などの完全マネージド型サービスは、自動的にデータとアプリケーションを複数の AZ にレプリケートします。 ミラノの AWS リージョンは、イタリアのエンドユーザーへのサービス提供を目的とするお客様に低レイテンシーを提供すると共に、オーストリア、ギリシャ、およびブルガリアなどの他の国々からのお客様へのサービス提供時にも、その他の既存 AWS リージョンより優れたレイテンシーを提供します。その成果は、エンドユーザーのラストマイルネットワークにおける接続の品質、キャパシティー、および距離に応じて異なる場合があります。 政府、ヘルスケア、および金融サービスで業務を行うお客様など、データレジデンシーの要件および規制があるイタリアのお客様にとっては、国内インフラストラクチャも同じく重要です。 イタリアの AWS 現在 AWS […]

 Amazon EventBridge は、アプリケーションを簡単に接続できるようにするサーバーレスイベントバスです。AWS サービスのデータ、独自のアプリケーション、Software-as-a-Service (SaaS) パートナーとの統合を使用できます。昨年の re:Invent では、EventBridge スキーマレジストリと検出のプレビューで、イベントの構造 (スキーマ) を中央に保存する方法を導入しました。また、Java、Python、Typescript 用にイベントを処理するコードを生成することにより、コード内のイベントの使用を簡素化しました。 本日より、EventBridge スキーマレジストリが一般公開され、リソースポリシーのサポートが追加されたことをお知らせいたします。リソースポリシーにより、異なる AWS アカウントと組織間でスキーマリポジトリを共有できます。このようにして、異なるチームの開発者は、別のチームが共有レジストリに追加したスキーマを検索して使用できます。 EventBridge スキーマレジストリリソースポリシーの使用 企業は、一般的にさまざまなサービスに取り組んでいるさまざまな開発チームを抱えています。より具体的な例を示すために、互いに通信を行う必要があるサービスに取り組んでいる 2 つのチームを見てみましょう。 CreateAccount 開発チームは、ウェブ/モバイルクライアントからリクエストを受信して、会社の新しい顧客アカウントを作成するフロントエンド API に取り組んでいます。 FraudCheck 開発チームは、新しく作成されたアカウントのデータをチェックするバックエンドサービスに取り組み、それらが偽物であるリスクを推定します。 各チームは、独自の AWS アカウントを使用してアプリケーションを開発しています。 EventBridge を使用すれば、次のアーキテクチャを実装できます。 フロントエンドの CreateAccount アプリケーションは、Amazon API Gateway を使用して、Python で記述された AWS Lambda 関数を使ってリクエストを処理します。新しいアカウントが作成されると、Lambda 関数はカスタムイベントバスで ACCOUNT_CREATED イベントを発行します。 バックエンドの FraudCheck Lambda 関数は Java で作成されており、ACCOUNT_CREATED イベントを受信して Amazon Fraud Detector […]

 ソフトウェアビルドの自動化は、DevOps のベストプラクティスを採用するための重要なステップです。これを支援するために、フルマネージド型の継続的インテグレーションサービスである AWS CodeBuild を構築しました。これは、ソースコードをコンパイルし、テストを実行し、デプロイの準備ができたパッケージを生成します。 しかし、お客様のビルドプロセスには非常に多くのカスタマイズの選択肢があり、ソフトウェアビルドに必要なさまざまなアクティビティを調整するために、開発者が独自のカスタムワークフローを作成することに時間を費やしていることがわかりました。たとえば、一部のテストを実行し、もしくは実行しないこととし、またはクイックフィックスをデプロイする必要がある場合にコードの静的分析をスキップしたい場合があります。 単体テストの結果に応じて、さまざまなアクションを実行したり、SNS を介して通知を受けたりしたい場合があります。 これを簡素化するため、本日、新しい AWS Step Functions の CodeBuild とのサービス統合をリリースします。これで、ステートマシンの実行中に、ビルドの開始または停止、ビルドレポートサマリーの取得、および過去のビルド実行レコードの削除ができるようになります。 これにより、独自のワークフロー主導のビルドプロセスを定義し、手動または自動でトリガーできます。たとえば、次のことができます。 Amazon EventBridge ルールを使用して、定期的に (夜間ビルドの場合)、または何かが発生したときに (AWS CodeCommit リポジトリへのプルリクエストなど)、ビルドワークフローを開始します。 Amazon API Gateway を使用して、ステートマシンへの直接統合で、またはワークフローを開始する前に入力ペイロードの有効性をチェックする AWS Lambda 関数を介して、GitHub などのサービスによって呼び出すことができる webhook を構築します。 この投稿で説明されているように、AWS CodePipeline アクションの動作をカスタマイズします。 この統合により、Step Functions の全機能を使用して、ソフトウェアのビルドを自動化できます。たとえば、Parallel 状態を使用して、ビルドの独立したコンポーネントの並列ビルドを作成できます。コードリポジトリ内のすべてのブランチのリストから始めて、Map 状態を使用して、各ブランチに一連のステップ (自動化ビルド、ユニットテスト、統合テスト) を実行できます。 同じワークフローで他の Step Functions のサービス統合を活用することもできます。 たとえば、メッセージを SQS キューに送信してアクティビティを追跡したり、Amazon ECS とAWS Fargate を使用して構築したコンテナ化されたアプリケーションを開始したりできます。 ワークフロー主導のビルドプロセスのために Step Functions […]

 EC2 インスタンスを開始するとき、または S3 バケットにデータを保存するとき、AWS リージョンが何であるかをあまり気にかけない向きもあります。現在、世界中に 22 か所あるリージョンはグローバルマップでは点のように見えますが、アプリケーションを実行し、高可用性とフォールトトレランスを備えたデータを格納できるように設計されています。実際、各リージョンは複数のデータセンターで構成されており、地理的にはアベイラビリティーゾーン (AZ) と呼ばれる場所に分けられています。 カナダのお客様をサポートするために、本日 AWS カナダ (中部) リージョンに 3 番目の AZ を追加したことをお知らせいたします。 この 3 番目の AZ は、スケーラブルかつフォールトトレラントで可用性の高いアプリケーションを設計する柔軟性をお客様に提供し、カナダでの AWS のサービスを強化します。 3 年前の 2016 年 12 月にカナダ (中部) リージョンをオープンしました。この 3 番目の AZ を導入することで、利用可能なサービスの数が 3 倍以上になります。 各 AZ は異なる地理的な場所にあり、リージョンの可用性に影響を与える単一のイベントのリスクを大幅に低減するのに十分な距離を取りながら、迅速なフェイルオーバーと同期レプリケーションを必要とするビジネスの継続性に影響するアプリケーションにとっては十分に近い所に位置しています。たとえば、カナダ (中部) リージョンはケベック州のモントリオールエリアにあり、次の新しい AZ は、カナダ本土の一番近い AZ から直線距離にして 45 km/28 マイル以上離れています。 リージョンと AZ を配置する場所は、レイテンシーや距離だけでなく、リスクプロファイルも考慮して慎重に考え抜かれています。リスクプロファイルを低く保つために、場所を選定する前に、洪水やその他の環境要因に関連する何十年分ものデータを調べます。モントリオールは、電力網を破壊し、1,000 を超える送電鉄塔を破壊した大規模な猛吹雪によって […]

 クラウドでアプリケーションをビルドして実行するとき、どのくらい「正しくやっているか」を自問していますか? 実際、これは非常に良い質問です。私たちは良い答えを得るために、AWS Well-Architected フレームワークを 2015 年に公開しました。これは、ワークロードをベストプラクティスと比較し、改善方法に関するガイダンスを得るための正式アプローチです。今日、「Well-Architected フレームワーク」は、顧客とパートナーがクラウドアーキテクチャを設計および評価するための一貫した方法を提供します。この方法は、5 つの柱に基づいています。 優れた運用効率 セキュリティ 信頼性 パフォーマンス効率 コストの最適化 より多くのワークロード固有のアドバイスを提供するために、2017 年に「レンズ」の概念でフレームワークを拡張し、一般的な視点を超えて特定のテクノロジードメインに参入しました。現在、使用できるレンズは 3 つあります。 サーバーレス ハイパフォーマンスコンピューティング (HPC) IoT (モノのインターネット) 何かを改善するには、最初に何をどのように測定するかを決める必要があります。より構造化された方法でワークロードを確認できるようにするために、AWS マネジメントコンソールで利用できる無料ツールである AWS Well-Architected Tool を 2018 年にリリースしました。ここでは、ワークロードを定義し、5 つの柱に関する質問に答えることができます。 Well-Architected Tool はさまざまな方法で使用できます。以下に例を示します。 特定のアプリケーションで作業している場合、ツールを使用してリスクを評価し、改善すべき領域を見つけることができます。 複数のアプリケーションを担当している場合は、ツールを使用して、すべてのアプリケーションの現在のステータスを確認できます。 本日、レンズを Well-Architected Tool に適用する機能を追加しました。最初にサーバーレスレンズをご利用いただけます。 AWS Well-Architected Tool でサーバーレスレンズを使用する Well-Architected Tool コンソールで、ワークロードを定義することから始めます。現在、Amplify フレームワークを使用してモバイルアプリのバックエンドを構築しています。簡単なゲームになりますが、ユーザーのデータを保存するために DynamoDB グローバルテーブルを使用し、アプリケーションは 2 つの AWS リージョンで実行されます。AWS […]

アプリケーションを構築または移行する際に、多くの場合、複数の計算ノード間でデータを共有する必要があります。 多くのアプリケーションはファイル API を使用し、Amazon Elastic File System (EFS) では AWS でそれらのアプリケーションを簡単に使用できます。他の AWS サービスおよびオンプレミスリソースからアクセスできる、スケーラブルでフルマネージド型の Network File System (NFS) を提供します。 EFS は、中断することなく、オンデマンドでゼロからペタバイトまで拡張します。また、ファイルを追加および削除すると自動的に拡大および縮小を行い、容量をプロビジョニングして管理する必要性を取り除きます。これを使用することにより、3 つのアベイラビリティーゾーン間で強力なファイルシステムの一貫性が得られます。EFS パフォーマンスは、必要なスループットをプロビジョニングするオプションを使用して、保存されているデータの量に応じて拡大します。 昨年、EFS チームは、EFS Infrequent Access (IA) ストレージクラスを導入することでコストの最適化に注力し、ストレージ料金が EFS 標準と比較して最大 92% 低くなりました。一定期間アクセスされていないファイルを EFS IA に移動するようにライフサイクル管理ポリシーを設定することにより、コストをすぐに削減できます。 現在、アクセスの管理、データセットの共有、EFS ファイルシステムの保護を簡素化する 2 つの新機能を導入しています。 NFS クライアントの IAM 認証と承認により、クライアントを識別し、IAM ポリシーを使用してクライアント固有の権限を管理します。 EFS アクセスポイントは、オペレーティングシステムのユーザーとグループの使用を強制し、オプションでファイルシステム内のディレクトリへのアクセスを制限します。 IAM 認証および承認の使用 EFS コンソールで、EFS ファイルシステムを作成または更新するときに、ファイルシステムポリシーを設定できるようになりました。これは、Amazon Simple Storage Service (S3) のバケットポリシーに類似した […]

Amazon Comprehend は、機械学習を使用して構造化されていないテキストからインサイトを見つける自然言語処理 (NLP) サービスです。非常に使いやすく、機械学習の経験は必要ありません。 Comprehend は特定のユースケースに合わせてカスタマイズできます。たとえば、ドキュメントを独自のカテゴリに整理するカスタムドキュメント分類子を作成したり、特定の用語のテキストを分析するカスタムエンティティタイプを作成したりできます。 ただし、医療用語は非常に複雑で、医療分野固有のものである場合があります。 Amazon Comprehend Medical は HIPAA に対応した自然言語処理サービスで、機械学習を使用して構造化されていないテキストから関連する医療情報の抽出を簡単に行うことができます。Comprehend Medical を使用すると、医師のメモ、臨床試験報告書、患者の健康記録などのさまざまなソースから、健康状態、薬、投与量、強度、頻度などの情報を短時間で正確に収集できます。 今日、Comprehend Medical が抽出した情報を医療オントロジーにリンクする機能を追加しています。 オントロジーは、そのドメインに存在する概念、その属性、それらの関係を定義して表すドメインの宣言モデルを提供します。通常、ナレッジベースとして表され、ナレッジを使用または共有する必要があるアプリケーションで利用可能になります。オントロジーは、健康情報学の中で、健康関連ドメインの正式な記述にあたります。 Comprehend Medical がサポートするオントロジーは次のとおりです。 ICD-10-CM では、健康状態をエンティティとして識別し、診断、重症度、解剖学的区別などの関連情報をそのエンティティの属性としてリンクします。 これは、集団健康分析を行うときや、提供された医療サービスに基づいて保険会社から保険金を受けとるとき、非常に役立つ診断コードセットです。 RxNorm では、薬をエンティティとして識別し、投与量、頻度、強度、投与経路などの属性をそのエンティティにリンクします。 医療従事者はこれらの概念を使用して、薬の処方確認のようなユースケースを可能にします。これは、患者が服用しているすべての薬のリストを可能な限り正確に作成するプロセスです。 Comprehend Medical はオントロジーごとに、潜在的な一致においてランク付けされたリストを返します。信頼スコアを使用して、どの一致が正しい意味なのか、またはどの一致をさらに検討しなければならないのかを決定できます。どのように機能するかは、例を通して見てみましょう。 オントロジーリンクの使用 Comprehend Medical コンソールでは、構造化されていない医師のメモを入力することから始めます。 最初は、Comprehend Medical で既に利用可能ないくつかの機能を使用して、医療および保護医療情報 (PHI) のエンティティを検出します。 認識されたエンティティ (詳細についてはこの記事を参照) の中には、いくつかの症状と薬があります。薬は包括的に、またはブランドとして認識されます。これらのエンティティの一部をより具体的な概念につなげる方法を学びます。 新しい機能を使用して、これらのエンティティを医薬品の RxNorm 概念にリンクします。 テキスト内で、薬に言及している部分のみが検出されます。詳細な答えには、さらに多くの情報があります。 たとえば、検出された薬の 1 つを見てみましょう。 用語「クロニジン」は、始めて登場 (上記入力テキストの 2 行目) したときに、RxNorm オントロジーの一般的な概念 (下の画像の左側) にリンクされます。 「クロニジン」という用語が […]

特にサーバーについて考える必要がない場合は、時間はあっと言う間に過ぎていきます。AWS Lambda は 5 年目を迎えました。チームは常に、顧客がより簡単な方法で、アプリケーションを構築して実行できるようにする新しい方法を探しています。 ミッションクリティカルなアプリケーションがサーバーレスに移行するにつれて、顧客はアプリケーションのパフォーマンスをさらに制御する必要があります。 本日、プロビジョニングされた同時実行数を開始します。これは、関数を初期化し、2 桁のミリ秒以内に応答するためのハイパーレディを維持する機能です。 ウェブおよびモバイルバックエンド、レイテンシーの影響を受けやすいマイクロサービス、同期 API などの対話型サービスの実装に最適です。 Lambda 関数を呼び出すと、呼び出しは実行環境にルーティングされ、リクエストが処理されます。関数がしばらく使用されていない場合、より多くの同時呼び出しを処理する必要がある場合、または関数を更新する場合、新しい実行環境が作成されます。実行環境の作成は、関数コードのインストールとランタイムの開始を処理します。デプロイパッケージのサイズやランタイムとコードの初期化時間に応じて、新しい実行環境にルーティングされる呼び出しのレイテンシーーが発生する可能性があります。このレイテンシーは通常、「コールドスタート」と呼ばれます。 ほとんどのアプリケーションでは、この追加のレイテンシーは問題になりません。ただし、一部のアプリケーションでは、このレイテンシーは許容されない場合があります。 関数のプロビジョニングされた同時実行を有効にすると、Lambda サービスは実行環境のリクエスト数を初期化して、呼び出しに応答する準備ができるようにします。 プロビジョニングされた同時実行の設定 同じ Java コードを使用し、Amazon API Gateway によってトリガーできる 2 つの Lambda 関数を作成します。本番稼働ワークロードをシミュレートするために、これらの関数は、初期化段階で 1,000 万回、呼び出しごとに 20 万回の数学的計算を繰り返しています。計算は java.Math.Random と条件 (if …) を使用して、コンパイラの最適化 (反復の「ループ解除」など) を回避します。各関数には 1 GB のメモリがあり、コードのサイズは 1.7 MB です。 2 つの関数のいずれかでのみプロビジョニングされた同時実行を有効にして、同様のワークロードに対する反応を比較できるようにします。Lambda コンソールで、いずれかの機能を選択します。構成タブに、新しいプロビジョニングされた同時実行設定が表示されます。 設定を追加を選択します。プロビジョニングされた同時実行は、特定の Lambda 関数バージョンやエイリアスに対して有効にできます ($LATEST は使用できません)。関数のバージョンごとに異なる設定を指定できます。エイリアスを使用すると、これらの設定を適切な関数バージョンに簡単に有効化できます。私の場合、AWS SAM AutoPublishAlias 関数設定を使用して、最新バージョンに更新し続けるエイリアスライブを選択します。プロビジョニングされた同時実行の場合、500 と保存を入力します。 現在、プロビジョニングされた同時実行の構成は進行中です。実行環境は、私の入力に基づいて同時に着信するリクエストを処理する準備ができています。 この間、関数は利用可能なままで、トラフィックを処理し続けます。 数分後、同時実行が準備状態になります。これらの設定により、最大 500 件の同時実行リクエストで、それらを処理するための準備が整った実行環境が見つかります。それを超えても、Lambda […]