Amazon Web Services ブログ

新機能: AWS Global Accelerator でのクライアント IP アドレス保持

AWS Global Accelerator は、着信するトラフィックを複数の AWS リージョンにルーティングするネットワークサービスです。これにより、グローバルなアプリケーションのパフォーマンスと可用性を向上させることができます。このサービスでは、当社が集積したエッジロケーションや遅延のないグローバルネットワークを利用することで、アプリケーション やネットワークの健全性、ユーザーの地理的位置などに基づき、トラフィック配信ができます。また、複数の AWS ロケーションからアナウンスされた静的な Anycast IP も使用できます (さらに詳しい情報は「New – AWS Global Accelerator for Availability and Performance」をご参照ください。 ) 。着信した TCP もしくは UDP トラフィックは、Application Load Balancer、Network Load Balancer、 Elastic IP Address にルーティングすることが可能です。 クライアント IP アドレス保持機能 当社は本日、AWS Global Accelerator に新たに加わった重要な機能について発表いたします。Application Load Balancer にトラフィックをルーティングしているお客様は、今後、ユーザーのクライアント IP アドレスを使い、エンドポイント上でのコード実行が行えるようになりました。この機能を使うと、特定の IP アドレス向けの処理を適用することができます。たとえば、IP アドレスに基づきフィルタリングを行うセキュリティグループの使用や、ユーザーの IP アドレスや所在地に応じた、カスタムコンテンツの提供などが行えます。加えて、ユーザーの所在地の地理的分布に関する統計情報を、IP アドレスを使いより精密に収集することも可能です。 クライアント IP […]

Read More

AWS System Manager Sessions Manager を使用した新しい機能 – Port Forwarding

昨今不変のインフラストラクチャアーキテクチャパターンを採用しているお客様が増えており、更新ごとにインフラストラクチャ全体を再構築およびリデプロイしています。SSH や RDP を介してサーバーに接続して、設定を更新したり、ソフトウェアの更新をデプロイしたりすることはほとんどありません。ただし、既存のアプリケーションをクラウドに移行する場合、Amazon Elastic Compute Cloud (EC2) インスタンスに接続して、さまざまな管理タスクまたは運用タスクを実行するのが一般的です。攻撃にさらされる面を減らすために、AWS では、ジャンプホストとも呼ばれる Bastion ホストを使用することをお勧めします。この特別な目的の EC2 インスタンスは、インターネットからのプライマリアクセスポイントになるように設計されており、他の EC2 インスタンスへのプロキシとして機能します。 EC2 インスタンスに接続するには、まず Bastion ホストに SSH/RDP 接続し、そこから宛先の EC2 インスタンスに接続します。 攻撃にさらされる面、Bastion ホストを管理するための運用上の負荷、および発生する追加コストをさらに削減するために、AWS Systems Manager Session Manager は、独自の Bastion ホストを実行および操作する必要も、 EC2 インスタンスで SSH を実行する必要もなく、 EC2 インスタンスに安全に接続できます。インスタンスに Systems Manager のエージェントがインストールされており、Systems Manager API を呼び出す IAM アクセス許可がある場合、AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (CLI) を使用して、Linux または Windows EC2 […]

Read More

Machine Learning ブログの新規記事: Amazon FSx for Lustre および Amazon EFS ファイルシステムを使用して、Amazon SageMaker のトレーニングをスピードアップする

分析アプリケーションと機械学習モデルをデプロイするには、容量とパフォーマンスをスケールインできるストレージが必要であり、高スループットと低レイテンシーのファイル操作でワークロードの需要に対応できます。 一般的なユースケースでは、データサイエンスチームが何らかの分析 (機械学習、ゲノミクスなど) を行うことを軸としています。AWS は、ビッグデータおよび分析ワークロード向けに、スケーラブルで耐久性のある可用性の高い2つのファイルソリューションを提供しています。Amazon EFS は、ML フレームワークや共有ノートブックシステム、そして Linux ベースのアプリケーションのためのクラウドネイティブの共有 NFS ストレージソリューションです。Faculty などの顧客は、分析ワークロードをスケーリングするために EFS を活用し、配信インサイトに対する俊敏性を向上させています。 Amazon FSx for Lustre は、データへのサブミリ秒アクセスを提供する Amazon S3 またはオンプレミスのデータを処理するための高性能ファイルシステムであり、最大で 1 秒あたり数百ギガバイトのスループットと数百万 IOPS の速度でデータを読み書きできます。Amazon FSx for Lustre は Amazon S3 とネイティブに連携し、コンピューティング集約型のファイルシステムでクラウドデータセットを簡単に処理することができます。Conductor Technologies は、クラウドレンダリングプラットフォームに FSx Lustre を用いることにより、TCO を削減しつつ、VFX およびアニメーションスタジオの顧客に簡素化とスケールをもたらします。 今週、AWS SageMaker チームは、EFS と FSx for Lustre の両方からデータにアクセスして意思決定を通知し、カスタマーエクスペリエンスを向上させることにより、顧客が機械学習のトレーニングジョブをスピードアップできるようになったことを発表しました。 機械学習ワークロードのための AWS ファイルストレージソリューションの詳細は、ブログ記事をご覧ください。

Read More

データベース移行のためのクロスアカウントの継続的デリバリーパイプラインの構築

開発を迅速化し、その品質を高めるには、アプリケーションのコード変更を管理してデプロイする継続的なデリバリー戦略を使用することができますが、データベース移行のための継続的デリバリーは、手動プロセスであることがほとんどです。 データベース移行のための継続的インテグレーションと継続的デリバリー (CI/CD) の導入には、次のようなメリットがあります。 自動化されたマルチアカウントセットアップによってデータベース移行がシンプル化される。 適用された変更の信頼レベルが向上する。 プロセスの再現が容易になる。 データベース移行がより高速で効率的になる。 データベースへの接続にジャンプステーションを使用する必要がないので、Amazon EC2 をプロビジョニングし、管理して、パッチを適用する必要がなくなる。 この記事では、マルチアカウントセットアップでデータベース移行を自動化するために AWS 開発者用ツール一式を設定する方法を説明します。対象読者は、AWS CloudFormation に関する知識がある開発者、ソリューションアーキテクト、およびデータベース管理者です。 このソリューションは、マルチアカウントおよびマルチ VPC の CI/CD データベース移行を紹介するために、4 つの AWS アカウントを使用します。 共有サービス – AWS CodePipeline および AWS CodeBuild などの継続的デリバリー/デプロイメントサービスに関連するすべてのツールのための中心的な場所です。共有サービスアカウントは AWS CodeCommit リポジトリもホストし、開発者はここにコードをプッシュできます。 開発、テスト、および本番 – Amazon RDS for SQL Server データベースを作成し、Secrets Manager を使ってデータベースの認証情報を保存するターゲットアカウントです。また、RDS for SQL Server インスタンスと同じ VPC およびプライベートサブネット内で、CodeBuild プロジェクトの作成と設定も行います。 前提条件 開発、テスト、および本番の各ステージを作成するための 3 […]

Read More

Amazon RDS Under the Hood: Multi-AZ

Amazon Web Services (AWS)のお客様はデータストアと、そのデータストアの高可用性にお客様のビジネスを委ねています。そのようなお客様に向けて、Multi-AZ配置は高可用性を実現する方法を容易に提供します。 Amazon Relational Database Service (Amazon RDS)でMulti-AZを有効にすることで、データの冗長かつ一貫した状態を維持します。もし、primaryデータベースサーバに問題が発生した場合は、standbyデータベースサーバに自動的に変更しデータへアクセスし続けられるようにします。2つのデータのコピーはそれぞれ別のAvailability Zones (AZs)内で管理されています(そのため、Multi-AZと呼ばれています)。別々のAvailability Zones を持つことで、両方のデータが同時に障害に見舞われるリスクを軽減させています。データの適切な管理、簡単な再構成、およびコピーへの信頼できるユーザーアクセスは、顧客環境が要求する高可用性要件に対処するための鍵です。 この投稿では、MySQL、MariaDB、PostgreSQL、およびOracleデータベースインスタンスのAmazon RDS Multi-AZ設定について説明します。Amazon RDS for SQL ServerおよびAmazon Auroraは、異なるテクノロジースタックを使用してマルチAZ機能を提供します。 基本デザイン Mult-AZ機能はデータベースアプリケーションとAmazon Elastic Block Store(Amazon EBS)ボリュームの間にあるレプリケーションレイヤーを使用して実装されています。このレイヤーは、アプリケーションの読み取りおよび書き込み要求を処理し、2つの個別のEBSボリュームコピーがある環境に適用されます。1つはローカルアクセス、もう1つはリモートアクセスです。 通常時は、レプリケーションレイヤーがインストールされた、2つのアクティブなAmazon EC2インスタンスがあります。 各インスタンスは、データの完全なコピーが行われているEBSボリュームを管理しています。この構成により、2つのインスタンスとそのボリュームがMulti-AZデータベースインスタンスとして稼働しています。 レプリケーションレイヤーは、TCP接続を介して互いに直接通信を行っています。 各インスタンスには特定のロールが割り当てられます。1つはプライマリであり、ユーザーがデータにアクセスするための外部エンドポイントを提供します。もう1つはスタンバイであり、プライマリから受信するすべてのデータを同期的に書き込むセカンダリインスタンスとして機能します。データベースの書き込みは、正常応答が呼び出し側アプリケーションに送り返される前に、データが両方のボリュームに適切に書き込まれます。ただし、読み取り操作は常にプライマリEBSボリュームを介して実行されます。データベースサーバープロセスは、スタンバイインスタンスで実行されていないため外部エンドポイントは公開されません。そのため、ユーザーはstandbyデータベースインスタンス上のデータのコピーは使用できません。 可用性を向上させるためにMulti-AZは、インスタンスの1つがプライマリロールにあることを一貫して保証し、データのコピーへのアクセスを提供します。もし可用性の問題が発生した場合、スタンバイインスタンスを自動的にプライマリロールに昇格させ、リダイレクトによって可用性を復元させます。 このイベントは、フェイルオーバーと呼ばれます。旧プライマリがまだ稼働している場合、スタンバイロールに降格されます。 新しいプライマリインスタンスへのリダイレクトは、DNSを介して提供されます。クライアントDNSクエリの結果に含まれるレコードのTTLは非常に短くなっています。アドレス情報の長期間のキャッシングを禁止することを目的としています。これにより、クライアントはフェールオーバープロセスで情報をより早く更新し、DNSリダイレクトの変更をより迅速に取得します。 以下の図が正常時のMulti-AZインスタンスの状態を示しています。 Figure 1: Multi-AZ instance データベースアプリケーション(黄色で表示されるDB APP)は、DNS)オレンジ色で表示)使用して、データへのアクセスを提供している現在の外部エンドポイントのアドレス情報を取得します。 このマルチAZインスタンスには2つのRDS DBインスタンスがあります。プライマリインスタンス(左側に緑色で表示)とスタンバイインスタンス)右側に青色で表示)です。この例では、DNSはアプリケーションをプライマリインスタンスEC2#1に向けており、Availability Zone#1で利用可能なEBS#1のプライマリコピーを提供しています。2つのEC2インスタンスの複製レイヤーが接続されています。アプリケーションが発行する書き込み操作は、2番目のインスタンスへの書き込みにもなります(パスは灰色で表示)。 レプリケーションレイヤーは、それ自体の可視性が制限されているため、より詳細な決定を下すことができません。たとえば、クライアントからの接続問題、ローカルまたはregionの停止、または予期せずサイレントな状態になったEC2ピアの状態などを知るすべがありません。このため、2つのインスタンスは、より重要な情報にアクセスし、インスタンスのステータスを定期的に監視する外部システムによって監視および管理されています。必要に応じて、管理システムは、可用性とパフォーマンスの要件が満たされてるためのアクションを実行します。 Multi-AZが提供する可用性と耐久性の改善は、最小限のパフォーマンスコストで実現しています。通常の使用例では、レプリケーションレイヤーが接続され、スタンバイEBSボリュームへの同期書き込み操作が発生します。スタンバイインスタンスとボリュームは、地理的に離れた個別のAvailability Zoneに配置されています。評価では、データベースのコミットへのオーバーヘッドが2ミリ秒から5ミリ秒増加していることが示されています。ただし、実際の使用例に対する実際の影響は、ワークフローに大きく依存します。ほとんどのお客様のMulti-AZインスタンスは、影響があったとしてもパフォーマンスにわずかな影響を示します。 この設計により、AWSはお客様のデータに対して99.95%の可用性を超えるサービスレベルアグリーメント(SLA)を提供しております。詳細については、Amazon RDSサービスレベルアグリーメントをご覧ください。 実装について ボリューム複製機能の設計は単純で簡単だと思われるかもしれません。しかし、実際の実装はかなり複雑です。これは、絶えず変化し、時には大きく変動する環境内で、2つのネットワークで接続された個別のインスタンスおよびボリュームが遭遇する可能性があるすべての事象を考慮する必要があるためです。 通常の進行中のレプリケーションは、すべてが適切に機能し、正常に動作していることを前提としています。EC2インスタンスが利用可能で、通常のインスタンス監視が機能し、EBSボリュームが利用可能で、ネットワークが期待どおりに動作しています。しかし、これらのピースの1つ以上が誤動作しているとどうなるでしょうか? 発生する可能性のある問題とその対処方法を見てみましょう。 […]

Read More

[AWS Black Belt Online Seminar] AWS AppSync 資料及び QA 公開

先日 (2019/8/22) 開催しました AWS Black Belt Online Seminar「AWS AppSync」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190821 AWS Black Belt Online Seminar AWS AppSync from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. AWS AppSyncのSubscriptionでは、Mutationの取りこぼしはないのでしょうか?例えば、「購読中に、Mutationの頻度が高い場合に、いくつかのMutationの結果が返らない」等です。あるいは、Lambdaのように、最低1回の受信(複数回受信することもある)ということはないのでしょうか? A. 基本的に設定されたSubscriptionは取りこぼし無く実行されます。但しAppSyncの制限事項としてGraphQL API ごとのスロットルレート、サブスクリプションの最大ペイロードサイズ等がありますのでその点はご注意ください。 Q.(少し調べれば出てくるかもしれませんが)実際に手を動かしてAppSyncの機能に触れられるチュートリアル的なものはありますか? A. AppSyncのチュートリアルに関しましてはこちらからご確認ください。 — 今後の AWS Webinar | イベントスケジュール 直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。 【AWS Innovate Online Conference】 AWS Innovate は、AWS クラウドを活用してビジネス革新を目指しているすべての IT リーダー及び IT プロフェッショナルを対象とした、最新のクラウド情報をお届けするためのオンラインカンファレンスです。この期間で、AWS初心者の方はAWSを始めるための準備を、AWS既存ユーザーの方は情報のアップデートにお役立ていただければと思います。 […]

Read More

[AWS Black Belt Online Seminar] Serverless モニタリング 資料及び QA 公開

先日 (2019/8/20) 開催しました AWS Black Belt Online Seminar「Serverless モニタリング」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190820 AWS Black Belt Online Seminar Serverless モニタリング from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. トレースは、Lambda以外にEC2やECSのアプリなどでも利用可能なのでしょうか? A. Amazon EC2: インスタンスを起動するときに、ユーザーデータのスクリプトを使用して自動的にデーモンを実行することができます。詳細は、AWS公式サイトを参照ください。 Amazon ECS: Amazon ECS で、X-Ray デーモンを実行する Docker イメージを作成し、それを Docker イメージリポジトリにアップロードして、Amazon ECS クラスターにデプロイできます。タスク定義ファイルでポートマッピングとネットワークモード設定を使用すると、アプリケーションがデーモンコンテナと通信できるようになります。詳細は、AWS公式サイトを参照ください。 — 今後の AWS Webinar | イベントスケジュール 直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。 【AWS Innovate Online Conference】 […]

Read More

複数の CPU/GPU にかけて並列化して、エッジでの深層学習の推論を高速化する

AWS のお客様は、レイテンシーを最小限に抑えるために、エッジで機械学習 (ML) 推論を実行することを選択することがよくあります。これらの状況の多くでは、ML 推論は多数の入力で個別に実行する必要があります。 たとえば、ビデオの各フレームでオブジェクトの検出モデルを実行する場合です。これらの場合、エッジデバイスで利用可能なすべての CPU/GPU で ML 推論を並列化すると、全体的な推論時間を短縮できる可能性があります。 最近、私のチームはこの最適化の必要性を認識しながら、お客様が産業用異常検出システムを構築するのを支援しました。このユースケースでは、一連のカメラが通過するマシンの画像を取得してアップロードしました (マシンごとに約 3,000 枚の画像)。お客様は、サイトのエッジデバイスにデプロイした深層学習ベースのオブジェクト検出モデルに各画像を入力する必要がありました。各サイトのエッジハードウェアは、2 つの GPU と複数の CPU を搭載していました。最初に、AWS IoT Greengrass コアにデプロイされた長期実行 Lambda 関数 (これについては記事の後半で詳しく説明します) を実装しました。この設定では、各イメージをエッジデバイスで順次処理します。 ただし、この設定では、エッジデバイスの単一の CPU および単一の GPU コアで深層学習推論が実行されます。推論時間を短縮するために、利用可能なハードウェアの全容量を活用する方法を検討しました。調査をいくらか行った後、(さまざまな深層学習フレームワークに対して) 複数の CPU/GPU (TensorFlow、MXNet、PyTorchなど) にトレーニングを分散させる多くの方法に関するドキュメントを見つけました。ただし、特定のホストで並列化を行う方法に関する資料は見つかりませんでした。 この投稿では、推論を並列化する方法をいくつか示し、コードスニペットの例とパフォーマンスベンチマークの結果を提供します。 この投稿では、データの並列処理のみに焦点を当てます。これは、入力データのリストを均等な部分に分割し、各 CPU/GPU コアがそのような部分 1 つを処理することを意味します。このアプローチはモデルの並列処理とは異なり、ML モデルを異なる部分に分割し、各部分を異なるプロセッサにロードする必要があります。データの並列処理は、その単純さにより、はるかに一般的で実用的です。 単一のマシンで ML 推論を並列化するのにどの点が難しいのでしょうか? マルチスレッドコードの記述に精通しているソフトウェアエンジニアであれば、上記の内容を読んで疑問に思うかもしれません。単一のマシンで ML 推論を並列化するのに、何が課題なんだろうかと。 これをよりよく理解するために、デバイスに少なくとも 1 つの GPU があると仮定して、単一の ML 推論をエンドツーエンドで実行するプロセスを手短に確認しましょう。 複数の […]

Read More

大規模なデータウェアハウスをダウンタイムなしで IBM Netezza から Amazon Redshift に移行する方法

最近、EMEA 地域の大企業がオンプレミスの IBM Netezza データウェアハウスの Amazon Redshift への移行を決定しました。データのボリューム (非圧縮容量 270 TB、および 27,000 個を超えるテーブル)、このデータを活用する相互接続されたシステムの数 (4,500 個を超えるビジネスプロセス)、かつダウンタイムなしという要件を考えると、このプロジェクトが困難であれどもやりがいがあるものなることは明らかでした。この会社は、データウェアハウスがデプロイされているデータセンターを 1 年以内に廃止することを計画していたので、時間的な制約もありました。 データウェアハウスは会社の中核を成す部分であり、あらゆる部門のユーザーが業務を遂行するために必要なデータを収集し、日報を生成することを可能にします。ほんの数年間で、クラスターにアクセスする事業部門はほぼ 3 倍に増加し、ユーザー数は当初の 5 倍となり、クラスターが設計された 1 日あたりのクエリ数 50 倍分のクエリが実行されるようになりました。レガシーデータウェアハウスは、これ以上これらの部門のビジネスニーズに対応できなくなり、毎晩の ETL プロセスの実行がその時間制限を超え、ライブクエリに時間がかかりすぎる原因となっていました。 この会社は、データセンターの廃止時期が近づいていたこともあり、ビジネスユーザー間における全般的な不満から移行の計画に踏み切り、IT 部門が新しいアーキテクチャの定義とプロジェクトの実施を担当することになりました。 アマゾン ウェブ サービス (AWS) の迅速かつスケーラブルな OLAP データウェアハウスであり、データウェアハウスとデータレイク全体における全データの分析をシンプル化してコスト効率性を高める Amazon Redshift は、この会社の問題を解決するために申し分ありませんでした。Amazon Redshift は今後の成長のための完全な伸縮性、および需要が高いピーク時を補うための同時実行スケーリングなどの機能を提供するだけでなく、簡単に統合できる分析サービスの完全なエコシステムも提供します。 この記事では、このお客様が綿密に計画された移行プロセスに従い、AWS Schema Conversion Tool (SCT) と Amazon Redshift のベストプラクティスを活用することによって、ダウンタイムなしで IBM Netezza から Amazon […]

Read More