Amazon Web Services ブログ

Amazon RDS または Amazon EC2 を使ってホストされているデータベースで実稼働ワークロードを実行するためのストレージのベストプラクティス

AWS は、OLTP ワークロードを処理するデータベースをホストするために複数のオプションを提供しており、Amazon EC2 インスタンスで独自のマネージドデータベースをホストする、または AWS が管理する Amazon RDS を使用することができます。RDS は、高可用性、自動バックアップ、データベースのアップグレード、OS パッチ、セキュリティ、およびリードレプリカを管理します。RDS は、クラウドネイティブのオプションである Amazon Aurora データベースエンジンも提供し、このエンジンは MySQL および PostgreSQL に対応しています。Aurora は、標準の MySQL と PostgreSQL データベースよりも優れたスループットを実現します。 Amazon RDS または Amazon EC2 を使ってホストされているデータベースで実稼働ワークロードを実行している時は、次のような疑問を思い浮かべたことがあるかもしれません。 最良のデータベースストレージタイプのオプションは何か? ストレージのパフォーマンス問題はどのように解決すればよいのか? EC2 インスタンスでホストされているデータベースに対する RAID 設定オプションには何があるのか? 最適なパフォーマンスのためのアプリケーション変更は何か? Amazon CloudWatch を使用してストレージパフォーマンスのトラブルシューティングを行うにはどうすればよいのか? Amazon RDS とAurora の運用パフォーマンスの違いは? この記事では Amazon RDS または EC2 インスタンスでホストされているデータベースで実稼働ワークロードを実行するためのストレージのベストプラクティスについて説明します。 テスト、QA、またはステージングの環境と比べて、実稼働ワークロードには高速で一貫した I/O パフォーマンスが必要です。リレーショナルデータベースは多目的に使用できますが、それらの最も一般的なユースケースはオンライントランザクション処理 (OLTP) […]

Read More

Amazon Redshift 用の AWS Step Functions を使用した ETL プロセスのオーケストレーション

現在のデータレイクは、大量の情報を使用可能なデータに変換する抽出、変換、ロード (ETL) 操作をベースとしています。この記事では、AWS Step Functions、AWS Lambda、AWS Batch を緩やかに結合して Amazon Redshift クラスターをターゲットにする ETLオーケストレーションプロセスの実装について詳しく説明します。 Amazon Redshift はカラムナストレージを使用するため、便利な ANSI SQL クエリを使用した迅速な分析的インサイトに最適です。Amazon Redshift クラスターを数分ですばやく増減して、エンドユーザーレポートとデータウェアハウスへのタイムリーなデータ更新の両方の厳しいワークロードに対応することができます。 AWS Step Functions を使用すると、拡張性に優れた繰り返し可能なワークフローを簡単に開発および使用できます。Step Functions によって、個々の Lambda 関数から自動化ワークフローを構築できます。各関数は個別のタスクを実行し、ワークフローのコンポーネントを迅速かつシームレスに開発、テスト、変更することを可能にします。 ETL プロセスは、データウェアハウスをソースシステムから更新し、未加工データをより簡単に使用できる形式に編成します。大半の組織は、ETL をバッチとして、またはリアルタイムの取り込みプロセスの一部として実行し、データウェアハウスを最新の状態に保ち、タイムリーな分析を提供します。完全に自動化されたスケーラビリティの高い ETL プロセスにより、通常の ETL パイプラインの管理に投入する必要がある運用上の労力を最小限に抑えることができます。また、データウェアハウスのタイムリーで正確な更新も保証されます。このプロセスをカスタマイズして、データを任意のデータウェアハウスまたはデータレイクに更新することができます。 また、この記事では、TPC-DS データセットを更新するためにワンクリックでサンプル ETL プロセス全体を開始する AWS CloudFormation テンプレートも提供しています。テンプレートへのリンクは、AWS CloudFormation を使用してワークフロー全体を設定するセクションにあります。 アーキテクチャの概要 次の図は、ETL ワークフローのオーケストレーションに関連するさまざまなコンポーネントのアーキテクチャの概要を示しています。このワークフローは Step Functions を使用して Amazon S3 からソースデータを取得し、Amazon Redshift データウェアハウスを更新します。 […]

Read More

Amazon EventBridge – SaaS アプリケーション用のイベント駆動型での AWS の統合

AWS のお客様の多くが、SaaS (Software as a Service) アプリケーショ ンを大いに活用しています。たとえば、カスタマーサービスとサポート用チケットの管理には Zendesk を、インシデント対応の処理には PagerDuty を、そしてリアルタイムモニタリングには SignalFX といったものを利用しています。これらのアプリケーションはそれ自体極めてパワフルですが、顧客独自のシステム、データベース、ワークフローと統合した場合には、さらに優れた機能を発揮します。 新しくなった Amazon EventBridge 最近一般的となってきたこうしたユースケースをサポートするため、本日、Amazon EventBridge の発表に至りました。CloudWatch イベントや EventBridge の基盤をなす強力なイベント処理モデル上にアプリケーションを構築することで、お客様独自の AWS アプリケーションが SaaS アプリケーションと簡単に統合できるようになります。SaaS アプリケーションはどこでもホストでき、AWS のお客様それぞれに固有のイベントバスにイベントを発行すればよいだけです。非同期のイベントベースのモデルは、迅速、クリーン、かつ操作しやすいです。パブリッシャー (SaaS アプリケーション) とコンシューマー (AWS で実行しているコード) は完全に分離されており、共有通信プロトコル、ランタイム環境、あるいはプログラミング言語に依存しません。シンプルな Lambda 関数を使って SaaS アプリケーションから発生するイベントを処理したり、イベントを他のさまざまな AWS ターゲットにルーティングすることもできます。インシデントやチケットのデータを Amazon Redshift に保存したり、カスタマーサポートのクエリに関する機械学習モデルをトレーニングしたりすることも可能です。 CloudWatch イベントについてすでに分かっている (もしかしたらお気に入りとなるかもしれない) 情報はすべて引き続き適用されますが、1 つだけ重要な変更があります。AWS のサービス、PutEvents への呼び出し、および他の認証済みアカウントからのイベントを受け入れる既存のデフォルトイベントバスだけでなく、サブスクリプションしている各パートナーアプリケーションもイベントソースを作成します。その後 AWS アカウントでイベントバスに関連付けることができます。任意のイベントバスを選択して、EventBridge ルールを作成し、着信イベントがルールと一致したときに呼び出すターゲットを選択できます。 本日からの利用開始の一環として、パートナープログラムも同時に開始されました。統合プロセスはシンプルで操作しやすく、たいていの場合開発期間は […]

Read More

AWS クラウド開発キット (CDK) – TypeScript と Python 用がご利用可能に

Infrastructure as Code を管理することで享受できるメリットは数多くあります。そのため、DevOps のプラクティスをうまく適用するきっかけとなることがよくあります。Infrastructure as Code によって、手動での実行手順に頼る代わりに、管理者と開発者の両方が構成ファイルを使用し、アプリケーションに必要なコンピューティング、ストレージ、ネットワーク、アプリケーションサービスのプロビジョニングを自動化できるようになります。 たとえば、Infrastructure as Code を定義すると、次のことが可能です。 インフラストラクチャとアプリケーションコードを同じリポジトリに保管する さまざまな環境、AWS アカウント、AWS リージョンにわたって実行されるインフラストラクチャの変更を再現かつ予測できるようにする 継続的なテストができるように、ステージング環境で本番環境を再現する ストレステストの実行に必要な時間だけ使用するパフォーマンステスト環境で、本番環境を再現する デプロイにインフラストラクチャの更新が含まれるように、コードの変更と同じツールを使用してインフラストラクチャの変更をリリースする コードレビューや小さな変更を頻繁にデプロイするなどのインフラストラクチャ管理に、ソフトウェア開発のベストプラクティスを適用する インフラストラクチャの管理に使用する設定ファイルは、従来的には YAML または JSON テキストファイルとして実装されていますが、この方法だと最新のプログラミング言語が持つ利点のほとんどを見逃してしまっています。特に YAML では、別のシステムへの転送中に切り捨てられたファイルを検出したり、あるテンプレートから別のテンプレートにコピーして貼り付けた際に行が欠落したことを検出するのは極めて困難です。 お好みのプログラミング言語が持つ表現力を大いに活用し、クラウドインフラストラクチャを定義できればいいと思いませんか? こうした考えから、昨年の開発者向けプレビューで、AWS クラウド開発キット (CDK) を発表しました。これは、使い慣れたプログラミング言語を使ってクラウドインフラストラクチャをモデル化およびプロビジョニングするための拡張可能なオープンソースソフトウェア開発フレームワークです。 そして本日、TypeScript および Python 用の AWS CDK の一般利用を開始することができました。 AWS CDK を使用すると、固有の要件を組み込んだ独自のカスタムコンポーネントを設計、構成、共有できます。たとえば、独自の標準 VPC を設定するコンポーネントや、それに関連付いたルーティングとセキュリティ設定を作成できます。あるいは、AWS CodeBuild や CodePipeline のようなツールを使用したマイクロサービス用の標準的な CI/CD パイプラインも作成可能です。 個人的に気に入っている点は、AWS CDK では同じプログラミング言語を使用し、さらに最新の IDE に組み込まれているオートコンプリートやパラメータサジェスチョンといったサポートを利用することで、インフラストラクチャを含むアプリケーションを IDE […]

Read More
週刊AWS

週刊AWS – 2019/7/8週

こんにちは、AWSソリューションアーキテクトの小林です。7月も中旬にさしかかり、そろそろ梅雨明けが待ち遠しい感じになってきました。まだ若干肌寒いのでシーズンは未だ来たらずですが、夏に食べたくなるのは素麺ですね。私は素麺が好きなのですが、いろいろな食べ方を工夫しています。最近お気に入りの食べ方は、麺つゆに種を抜いた梅干しを溶いて食べるやり方です。酸っぱい梅干しを使うのがコツなのですが、蒸し暑い時期にぴったりの爽やかな味になりますので、ぜひお試しあれ。

Read More

Amazon API Gatewayを使用したSAP IDocとAmazon S3の統合

Amazon Web Services (AWS)上でSAPワークロードを稼働している私たちのお客様は、同様にAWS上のデータレイクソリューションを使用することでデータと分析の変換に投資されています。これらのお客様は、さまざまなサードパーティソリューションを使用してSAPアプリケーションからデータを抽出することがあります。ただし、パフォーマンス向上とコスト削減のために、AWSソリューションを使用するネイティブ統合も必要とされています。 これらのお客様がSAPアプリケーションからデータを抽出するために使用する一般的なパターンは、IDocインターフェース/電子データ交換です。SAP NetWeaver ABAPベースのシステムは、長い間IDocをサポートしています。IDocは非常に安定したフレームワークであり、SAPシステムと非SAPシステム間でのマスターデータとトランザクションデータの配信を支えます。 SAP IDocをAmazon Simple Storage Service (Amazon S3)と統合するためのアーキテクチャ上のアプローチは、ブログ記事「Integrating SAP’s IDOC Interface into Amazon API Gateway and AWS Lambda」のように、既にSAPコミュニティで公開されています。しかしながら、これらのアプローチでは、本稼働環境で使用する上で重要なセキュリティ面がカバーされていません。不正なユーザーの脅威から守るためにビジネスクリティカルなAPIを保護することは重要です。 このブログ記事では、AWS Lambda オーソライザーとAmazon Cognitoで認証レイヤーを提供し、Amazon API Gatewayを使用してSAP IDocをAmazon S3に格納する方法を紹介します。

Read More

SAPファイル転送ワークロードのためのAWS Transfer for SFTP – 第1回

この記事は、AWSでパートナーソリューションアーキテクトを務めるKenney Antoney Rajanによるものです。 SAPのようなエンタープライズリソースプランニング (ERP)ソフトウェアを使用する多くの組織は、セキュアファイル転送プロトコル (SFTP)サーバーを稼働および保守して、ビジネス上の重要なデータをSAPから外部のパートナーシステムに安全に転送しています。この一連のブログ記事では、SAP Process Integration (SAP PI)とSAP Process Orchestration (SAP PO)、およびSAP Cloud Platform IntegrationとAWS Transfer for SFTP (AWS SFTP)を統合するための手順を紹介します。また、AWS SFTPがAmazon Simple Storage Service (Amazon S3)に格納するデータを後処理分析に使用する方法も紹介します。

Read More

Model Server for Apache MXNet を使って、独自の深層学習フレームワークを Amazon SageMaker で使用する

深層学習 (DL) フレームワークを使用すれば、機械学習 (ML) モデルを構築し、トレーニングできます。しかし ML モデルを本番環境でデプロイし、予測 (推論ともいう) をリアルタイムで処理するプロセスは複雑です。そのため ML の実践者は、これらのモデルをホストし推論リクエストを大規模に処理できる、スケーラブルかつパフォーマンスの高いモデルサーバーを構築する必要があります。 この問題に対処しようと、Model Server for Apache MXNet (MMS) が開発されました。MMS は極めてスケーラブルなだけでなく、すぐに使える推論サーバーです。MMS は ML/DL フレームワークに依存しないように設計されているため、どんな ML/DLフレームワークでトレーニングしたモデルでもホストできます。 この記事では MMS を利用して、運用中の ML/DL フレームワークまたはツールキットを使ってトレーニングしたモデルをホストする方法をご紹介します。本番用ホスティングには、Amazon SageMaker を使います。この PaaS ソリューションはインフラストラクチャを構築する数多くの作業を行ってくれるため、自身のユースケースに集中できます。 今回のソリューションでは、「Amazon SageMaker ホスティングサービスでの独自の推論コードの使用」で概説したアプローチを使用します。この記事では、必要とされるすべての依存関係、ライブラリ、フレームワークとその他のコンポーネントとともにモデルを使用する方法について説明します。それらを 1 つのカスタム Docker コンテナにコンパイルしてから、Amazon SageMaker でホストします。 MMS が ML/DL フレームワークに依存しないアーキテクチャーであることをお見せするため、PaddlePaddle フレームワークでトレーニングしたモデルを本番で投入することにしました。MMS 持ち込み (BYO) コンテナを使って、ML/DL フレームワークでトレーニングしたモデルを Amazon SageMaker で使用する手順を次の図に示しました。 この図が示すように、MMS BYO […]

Read More

Amazon Elasticsearch Service でのアラート設定

顧客はログ分析に Amazon Elasticsearch Service をよく使用します。Amazon ES では、インフラストラクチャからログを収集し、各ログ行を JSON ドキュメントに変換して、ドキュメントを一括 API に送信することができます。 変換されたログ行には多数のフィールドがあり、それぞれに値が含まれています。たとえば、Apache ウェブのログ行には、特に送信元 IP アドレスフィールド、リクエスト URL フィールド、およびステータスコードフィールドが含まれます。多くのユーザーは、Kibana を使用してダッシュボードを構築し、インフラストラクチャを視覚的にモニタリングします。それらのフィールドのデータから明らかであるように、アプリケーションの使用状況、バグ、またはセキュリティ問題に直面しています。たとえば、HTTP 5xx ステータスコードの数をグラフ化してから、変化を監視して対応できます。5xx コードが急増した場合は、おそらくサーバーに問題があります。しかし、このシステムでは Kibana を手動でモニタリングしなければなりません。 4 月 8 日、Amazon ES はイベントのモニタリングとアラートのサポートを開始しました。この機能を使用するには、設定した特定の条件であるトリガーを持つモニタ (スケジュールされたジョブ) を操作して、モニタにアラートを送信するタイミングを指示します。アラートは、トリガー条件が発生したことを通知します。トリガーを引き起こすと、モニタが動作を開始し、送信先にメッセージを送ります。 この記事では、シミュレートされた IoT Device Farm を使用してデータを生成し、Amazon ES に送信します。 シミュレーターの概要 このシミュレーションは、センサーとデバイスといういくつかの重要部分で構成されています。 センサー シミュレーターのコアクラスはセンサーです。デバイスには、さまざまなパターンの浮動小数点値をシミュレートするセンサーがあります。呼び出したとき、各センサーのレポートメソッドはセンサーの値を更新して返します。センサーにはいくつかのサブクラスがあります。 SineSensor: 現在のタイムスタンプに基づいて正弦波を生成します。 ConstSensor: 定数値を生成します。このクラスには、特定の値を中心にして変動するランダムな「ファズ」係数が含まれています。 DriftingSensor: 開始値で連続的なランダムドリフトを可能にします。 MonotonicSensor: ランダムファズで、一定のデルタで値を増やします。 この記事では、MonotonicSensor を使用してその値を増やし続けて、設定したアラートを強制的に違反しました。 汎用一意識別子 (UUID) と追跡するメトリックのラベルからセンサーを識別できます。センサークラスのレポート機能は、タイムスタンプ、センサーの […]

Read More

Amazon Aurora PostgreSQL Serverless が一般利用可能に

データベースは通常、ソフトウェアアーキテクチャの最も重要な部分であり、データベースの管理、特にリレーショナルデータベースの管理は容易ではありませんでした。このため、Amazon Aurora の自動スケーリングバージョンであり、アプリケーションのワークロードに基づいて自動的に起動、シャットダウン、スケールアップまたはスケールダウンできる Amazon Aurora Serverless を開発しました。 Aurora Serverless の MySQL 互換エディションは少し前から入手可能です。本日、Aurora Serverless の PostgreSQL 互換エディションが一般利用可能になったことをお知らせいたします。 詳細を説明する前に、Amazon Aurora 開発チームが、2019 年の米国計算機学会 (ACM) のデータ管理分科会 (SIGMOD) システム賞を受賞したことを祝福します。 Aurora Serverless を使用してデータベースを作成するときは、最小容量と最大容量を設定します。クライアントアプリケーションは、自動的にスケーリングされるリソースプールにワークロードをルーティングするプロキシフリートに透過的に接続します。リソースが「ウォーム」であり、リクエストに応えるために追加する準備ができているため、スケーリングは非常に高速です。   Aurora によるストレージの管理方法について、Aurora Serverless では変更はありません。ストレージ層は、データベースが使用するコンピューティングリソースから独立しています。事前にストレージをプロビジョニングする必要はありません。最小ストレージは 10GB です。データベースの使用量に基づいて、Amazon Aurora ストレージは自動的に最大 64TB まで 10GB 単位で増加し、データベースのパフォーマンスには影響しません。 Aurora Serverless PostgreSQL データベースの作成 それでは、Aurora Serverless PostgreSQL データベースを起動し、自動スケーラビリティが機能していることを確認しましょう。 Amazon RDS コンソールで、Amazon Aurora をエンジンとして使用してデータベースを作成することを選択します。現在、Aurora Serverless は PostgreSQL […]

Read More