Amazon Web Services ブログ

Amazon OpenSearch Service Multi-AZ with Standby が有効化されたドメインによる高可用性の実現: フェイルオーバーの詳細

Amazon OpenSearch Service は最近、Multi-AZ with Standby を導入しました。これは重要なワークロードに対して、強化された可用性と一貫したパフォーマンスをビジネスに提供するために設計されたデプロイメントオプションです。この機能により、マネージドクラスターはゾーンのインフラストラクチャ障害に対する回復力を保ちながら、99.99% の可用性を実現できます。

Amazon OpenSearch Service は Multi-AZ with Standby を利用した 99.99% の可用性をサポート

AWS は OpenSearch Service の新しいデプロイメントオプションである Multi-AZ with Standby を発表しました。これにより、高頻度の監視、迅速な障害検出、障害からの迅速な回復などの重労働を軽減し、インフラ障害が発生した場合でもドメインの可用性とパフォーマンスを維持できるようになります。Multi-AZ with Standby を使用すると、ドメインは 99.99% の可用性と一貫したパフォーマンスを実現できます。

Amazon DynamoDB のプロビジョンドキャパシティを使用した突発的なトラフィック増加への対処

テーブルでプロビジョンドキャパシティを使用する場合、突然のリクエストトラフィックの増加 ( スパイク ) に対して、スロットルされることなく対処するための最善の方法を検討するのは課題の一つです。スロットルは、リクエストレートが設定された制限を超えたことを DynamoDB が検知した場合に発生するサービス応答です。たとえば、テーブルの書き込み容量ユニット ( WCU ) を 10,000 にプロビジョニングしており、トラフィックが 20,000 を消費するレートでアクセスされた場合、やがてスロットルが発生し、スロットルされたリクエストを処理するためリトライをする必要があります。
突発的かつ長時間続くトラフィックスパイクほど、テーブルにスロットルが発生する可能性が高まります。ただし、突発的なトラフィックに対して、スロットルの発生を避けることができないわけではありません。ここでは、トラフィックのスパイクに対処するための 8 つの設計と、それぞれの利点と欠点を紹介します。

AWS Glue を使用した個人情報の検出・マスキング・編集および Amazon OpenSearch Service へのロード

大企業や中小企業を問わず、多くの組織がアマゾン ウェブ サービス(AWS)上で分析ワークロードの移行と近代化に取り組んでいます。AWS への移行にはさまざまな理由がありますが、主な理由の 1 つは、インフラストラクチャのメンテナンス、パッチ適用、モニタリング、バックアップなどに時間を費やす代わりに、フルマネージドサービスを利用できることです。リーダーシップと開発チームは、現在のインフラストラクチャのメンテナンスではなく、現在のソリューションの最適化や新しいユースケースの実験などにより多くの時間を費やすことができます。

AWS Step Functions の Distributed Map と再実行機能を使用した効率的な ETL パイプラインの構築

AWS Step Functions は、完全マネージドのビジュアルワークフローサービスで、AWS Glue、Amazon EMR、Amazon Redshift などのさまざまな抽出・変換・読み込み (Extract, Transform, Load; ETL) テクノロジーを含む複雑なデータ処理パイプラインを構築できます。Step Functions では、失敗、中止、タイムアウトしたステートからワークフローを再実行できるようになりました。この投稿では、Step Functions のDistributed Map ステートを使用して、Amazon Relational Database Service (Amazon RDS) のテーブルからデータをエクスポートする ETL パイプラインジョブをご紹介します。その後、障害をシミュレートし、新しい失敗したステートから再実行する機能を使用して、障害が発生したタスクを障害発生地点から再起動する方法をデモンストレーションします。

← Older posts
Newer posts →