Amazon Web Services ブログ

自律走行シリーズ 1 回目のブログでは、Donkey カーの構築と Amazon EC2 インスタンスでパイロットサーバーをデプロイしました。そして、2 回目のブログでは Donkey カーの運転を学び、Donkey カーが自律走行を学びました。今回のブログでは、Donkey カーから AWS にテレメトリをストリーミングするプロセスをご紹介します。スケーラブルで信頼性が高く、当社の接続済み自律走行車など様々な接続済みデバイスに対し多機能な一連のサービスを提供する AWS IoT を使用します。 1) AWS 自律走行車を構築し re:Invent の Robocar Rally でレースに参加 2) 自律走行車の構築 パート 2: 自律走行車の運転 3) 自律走行車の構築 パート 3: 自律走行車の接続 4) 近日中に公開予定 AWS IoT のセットアップ 自律走行車は運転中に絶え間なくテレメトリをストリーミングします。自律走行車が稼働していない場合は収集するテレメトリがないため、リソースを使用しないことで無駄を避けます。ワークロードに対応するため、アーキテクチャ全体の稼働においてはサーバーレステクノロジーに依存します。開始するには、まず AWS IoT を使用してフリートモニタリングサービスを設計します。同じ基本的なアーキテクチャを使用して、その数に制限なく自律走行車に使用できます。次の図はフリートモニタリングサービスのアーキテクチャを示しています。 同ソリューションのコンポーネントは、論理的な機能 (および AWS のサービス) 別に色分けされ、ソリューションの各コンポーネントが安全でスケーラブルであり、完全に使用量ベースであることが示されています。この種のオペレーションモデルは様々なビジネスモデルで役立ち、幅広いサイズの顧客にとっても便利です。週末に趣味で自律走行車をレースしてラップタイムを比較したり、自動車メーカーが独自の接続された車両プラットフォームを開発したい場合でも、AWS IoT は安全でスケーラブルな使用量ベースのコスト構造を提供しています。 このソリューションは緑の網掛け部分の Donkey カーから始めます。次にデータが IoT サービスを通過してピンクのセクションに移動します。このセクションは DynamoDB の短期間用データストレージです。その後、S3 […]

–この記事はAWS セキュリティ・アシュアランス本部の寄稿です– 2016年12月に AWS Artifact のサービスが開始され監査レポート等コンプライアンスに関する重要な情報を提供してきましたが、2017年11月より同サービスにおいて、日本のお客様に向けて「日本準拠法に関する AWS カスタマーアグリーメント変更契約」の手続きが可能な新機能の提供を開始しました。これにより、AWS Artifact を通じて日本準拠法に関する AWS カスタマーアグリーメント変更契約をリアルタイムに締結または終了することが可能となっています。 日本準拠法に関する AWS カスタマーアグリーメント変更契約とは、現在お客様がご利用中の AWS アカウントに適用されている、 AWS カスタマーアグリーメントの準拠法および管轄裁判所を変更する契約を指します。この契約を有効にすることで、 AWS カスタマーアグリーメントの準拠法を日本法に変更し、更に、同契約に関するあらゆる紛争に関する第一審裁判所を東京地方裁判所に変更することができます。 従来、AWSカスタマーアグリーメントの準拠法および管轄裁判所を変更する際に、その都度、書面で契約を締結して頂く必要がありましたが、AWSアカウントのマネジメントコンソールからお客様ご自身で受諾（有効に）することで、お客様の手間を省略することが可能となっています。 AWSでは今後も日本のお客様の声に耳を傾け、サービスの拡充に努めていきます。 【AWS Artifactの操作方法】 AWS Artifactを使用した日本準拠法に関するAWSカスタマーアグリーメントの変更方法、操作方法については下記のリンクから動画をご参照ください。より詳細なAWS Artifactの情報については以下のartifactのページをご参照ください。 https://aws.amazon.com/jp/artifact/   【留意事項】  日本準拠法に関する AWS カスタマーアグリーメントは、請求連絡先アドレスが日本国内にあるアカウントに対してのみ提供されるものです。 複数のアカウントをお持ちのお客様の場合、アカウント毎に有効にして頂く必要があります。 既に個別に書面でカスタマーアグリーメントの準拠法および裁判管轄を変更する契約を取り交わしているお客様については、再度締結いただく必要はございません。 その他の詳細については下記のページをご参照ください。 https://aws.amazon.com/jp/artifact/faq/   – AWS セキュリティ・アシュアランス本部    

この記事は、Amazon Web Services(AWS)のソリューション アーキテクト、Harpreet SinghとDerek Ewellによるものです。 VPCサブネットのゾーニングパターンに関するシリーズ記事の第1回目では、SAPアプリケーションへのいくつかの接続方法を紹介し、内部専用接続のためのAmazon Virtual Private Cloud(Amazon VPC) サブネットのゾーニングパターンについて詳細を説明しました。第2回目では、従来のアプリケーションにおけるネットワークのゾーニングをAWS上でどのように実装できるか説明しました。このシリーズの最後の記事として、内部接続と外部接続の両方を必要とするSAPアプリケーションの接続パターンを説明します。外部ソースからの接続は管理されていてもよく(つまり、既知の外部の関係者を含む)、管理されていない(つまり、公開されていてもよい)場合もあります。両方のシナリオについて説明します。 内部および管理された外部接続 外部向けインターフェースに対する信頼された外部の関係者からの接続と、内部向けインターフェースに対するSAPと非SAPシステム間またはどちらかの間の接続が必要となる、SAP Process Orchestration(PO)とSAP Process Integration(PI)がこのシナリオの典型的な例です。内部向けインターフェースは簡単に管理できます。基本的には、ルートテーブル、ネットワークアクセスコントロールリスト(ACL)、およびセキュリティグループに適切なトラフィックを定義します。しかしながら、外部接続を安全に提供することには課題があります。そこで、信頼できる外部の関係者からのトラフィックの入口と出口に着目しましょう。典型的な選択肢が4つあります。 入口と出口の両方のための仮想プライベートネットワーク(VPN)接続 入口用のElastic Load Balancing、および出口用のネットワークアドレス変換(NAT)ゲートウェイ NATデバイス(NATインスタンスまたはNATゲートウェイ) リバースプロキシ VPN接続 (入口と出口) 信頼できる外部の関係者と専用の仮想接続を作成する場合は、VPCでVirtual Private Gateway(VGW)を使用するか、パブリックサブネット内にAWS Marketplaceで公開されているような独自のソフトウェアVPNサーバを使用することで、サイト間IPsec VPN接続を確立できます。 注釈   この記事のアーキテクチャ図では、簡単にするために単一のアベイラビリティゾーンで示しています。実際には、高可用性を実現するために、少なくとも2つのアベイラビリティゾーンにわたってソリューションを構成することをお勧めします。 図 1: 管理された外部接続のためのVPNコネクション Elastic Load Balancing (入口) / NATゲートウェイ (出口) Elastic Load Balancingには、次の3つのタイプがあります。 Classic Load Balancer Network Load Balancer Application Load Balancer […]

AWS コミュニティヒーロープログラムでは、世界中の腕の良い AWS デベロッパーによって行われている革新的な作業の一部を紹介しています。このようなヒーローは、クラウドの専門知識と、コミュニティ構築および教育に対する熱意を組み合わせて、ソーシャルメディアや実際に顔合わせができるイベントで時間と知識を共有しています。また、カンファレンスで積極的にコミュニティ型の方向性を促進しています。今年の re:Invent では、多くのヒーローが Monday Community Day トラックでお話しする予定です。 大変うれしいことに、今年の 11 月、AWS のクラウド革新者ネットワークに 4 名のヒーローを迎えます。それでは早速、AWS コミュニティの新しいヒーローをご紹介します。 Anh Ho Viet Thorsten Höger Becky Zhang Nilesh Vaghela Anh Ho Viet Anh Ho Viet は、AWS ベトナムのユーザーグループ の設立者でありながら、OSAM の共同設立者兼 CEO、ベトナムの AWS コンサルティングパートナー、AWS 認定ソリューションアーキテクトという肩書きを持つクラウド愛好家です。 OSAM で、Anh と彼の熱意あふれるチームは、SMB からエンタープライズに至るまで、多くの企業の AWS クラウドへの移行をサポートしてきました。AWS の移行やコンサルティング、アーキテクチャ、ソリューション設計など、そのサービス範囲は多岐にわたります。OSAM に対する Anh のビジョンは、クラウドサービスプロバイダーの範囲にとどまりません。同社は、完全な AWS エコシステムをベトナムに構築し、トレーニングやコラボレーションといった活動を通して、ベトナムの他の企業に AWS パートナーになる機会を与える取り組みを行っています。 2016 […]

  Knievel Co は、アマゾン ウェブ サービスのデータベースエンジニアです。 このブログ記事では、Oracle データベースを PostgreSQL に移行する方法の概要について説明します。データベース移行の2つの主要部分は、スキーマの変換とデータの複製です。）AWS スキーマ変換ツール (AWS SCT) と AWS Database Migration Service (AWS DMS) を使用して､これら 2 つの部分に取り組む方法について説明します。 SCT と DMSについて説明する前に、予備的な手順を実行する必要があります｡これらは､すべての移行に役立つことが判明しています。移行を容易にする方法の 1 つは、移行の前に､通常更新フェーズと呼ばれるものを行うことです｡このフェーズでは、Oracle データベース内のオブジェクトのインベントリを作成し、いくつかの決定を下します。 最初に、不要になったオブジェクトを削除します｡オブジェクトの移行にかかる時間は誰も気にかけませんが､無駄にしないでください。また､不要になった履歴データを削除することもできます。一時的なテーブルや過去のメンテナンス時のテーブルのバックアップコピーなど、不要なデータを複製するために時間を無駄にすることはありません。次に、LOB、CLOB、LONG などに保存されているフラットファイルおよび長い文字列を Amazon S3 または Amazon Dynamo DB に移動します｡このプロセスではクライアントソフトウェアの変更が必要となりますが、データベースが簡素化されサイズが削減されることで、システム全体がより効率的になります。最後に、PL/SQL パッケージとプロシージャを移動します｡特にビジネスロジックを含むものをクライアントソフトウェアに戻してみます。これらのオブジェクトは、SCT が変換できない場合は手動で変更する必要があります。 次の手順は、異なるデータベースエンジン (この場合は Oracle から PostgreSQL へ) に移行するための手順です。別のプラットフォームに移動していない場合は、データベースを移動するためのより適切なネイティブツールやその他のテクニックがあります。 ターゲットデータベースでスキーマを作成します。 ターゲットデータベースの外部キーとセカンダリインデックスを削除し、トリガーを無効にします。 データを複製するためのDMSタスクを設定します (全ロードと変更データキャプチャ (CDC))。 全ロードフェーズが完了したらタスクを停止し、外部キーとセカンダリインデックスを再作成します。 DMS タスクを有効にします。 […]

この記事はECSのSr. Software Dev EngineerのAnirudh Aithalの寄稿です。 2017年11月14日に、AWSはコンテナにElastic Network InterfaceをアタッチできるようにするAmazon ECSのTask Networkingを発表しました。 この記事では、ECSが管理するインスタンス(コンテナインスタンスと呼ばれます)上でContainer Networking Interfaceプラグインを使って、この新しいコンテナネイティブなawsvpcネットワークモードがどのように実装されているかを詳しくご紹介したいと思います。 こちらはAmazon ECSでタスクネットワークが動作するかにdeep diveしたものです。もし自身のコンテナ化したアプリケーションでどうやってタスクネットワークを使い始めれば良いかについて学びたい時には、Amazon ECSコンテナにCloud Native Networkingが登場をご覧下さい。Cloud Native Computing Foundation (CNCF)がContainer Networking Interface (CNI)プロジェクトをホストしており、Linuxコンテナでネットワークインターフェースを設定するためのプラグインを書くための仕様やライブラリが含まれています。AWSのクラウドネイティブコンピューティングについての詳細は、Adrian CockcroftのCloud Native Computingについての投稿をご覧下さい。 コンテナインスタンスのセットアップ コンテナインスタンス上でのタスクネットワーク有効化の詳細をご説明する前に、ECSの典型的なインスタンスがどのようになっているかを見てみましょう。 上の図は典型的なコンテナインスタンスを示しています。ECS agentは自身もコンテナとして実行されているのですが、以下のような責任を負っています: EC2インスタンスをECSのバックエンドに登録 コンテナインスタンスに対してECSバックエンドが発生させたタスク状態の変化を、正しく適応 Dockerデーモンと会話しながら、コンテナの作成、開始、停止、監視 コンテナの状態とタスクの状態の遷移をECSバックエンドにリレー ECS agentはその管理下のコンテナのスーパーバイザーの様に動作するので、Dockerデーモン(Dockerのデフォルトネットワークモードで設定されたコンテナ用)、又はCNIプラグイン達(ネットワークモードがawsvpcで設定されたタスク内のコンテナ)のための、ネットワーク設定をする難しさをオフロードしてくれます。 いずれの場合にも、コンテナのネットワークスタックは、ネットワークのnamespaceを通じて設定されます。ip-netns(8)のマニュアルによると「ネットワークnamespaceは論理的なネットワークスタックのコピーで、自身のルーティング、ファイアウォールルール、ネットワークデバイスを持っています。」 とあります。ネットワークnamespaceの構成によって、ホスト上で動いているプロセスやコンテナ間でのネットワークスタックの隔離を可能としてくれます。 ネットワークnamespaceとCNIプラグイン CNIプラグインとは、CNI仕様を満たしコンテナのネットワーク接続性の設定を行う実行ファイル群です。CNIプロジェクトではプラグインの仕様を定義し、プラグインが利用するライブラリを提供することで、一貫していて信頼でき、かつ簡素なプラグイン用のインタフェースを提供してくれます。 コンテナやネットワークnamespaceを指定してプラグインを呼び出す時に、ADDコマンドでコンテナにネットワークインターフェースを追加したり、DELコマンドでそれを落としたりします。例えばリファレンスのBridgeプラグインは、ホストネットワークnamespaceの中にいるブリッジに対してホスト上の全てのコンテナを追加します。 このプラグインのモデルはECS agentの「コンテナのライフサイクルへの最小限の介入」というモデルと相性が良く、agentはコンテナのネットワーク設定の詳細について考慮する必要がなくなります。また拡張性の高いモデルなので、将来必要になった時には、agentが異なるプラグイン群を利用できるようにスイッチさせることもできます。最後に、これらプラグインは必要な時に呼び出されるだけなので、その死活監視をECS agentがする必要はありません。 ECS agentからCNIプラグインを呼び出す ECSがElastic Network Interfaceをインスタンスにアタッチし、agentに対しそのElastic Network Interfaceをタスク内のコンテナに対してプロビジョンするようにメッセージを送った時には、(任意のネットワークデバイスを使う) そのElastic […]

この記事はECSのSr. Software Dev EngineerのAnirudh Aithalの寄稿です。 2017年11月14日に、AWSはAmazon ECSのTask Networkingを発表しました。これによって、Elastic Network Interfaceを使ったAmazon EC2のネットワーク機能をタスクに持ち込むことができるようになります。 Elastic Network InterfaceはVPC内のインスタンスにアタッチすることができる仮想的なネットワークインタフェースです。EC2の仮想マシンを起動する時には、インスタンスにネットワークの機能を提供するために自動的に1つのElastic Network Interfaceがプロビジョンされます。 タスクは実行されるコンテナの論理的なグループです。これまでは、Amazon ECSで実行されるタスクはそれが動くEC2ホストのElastic Network Interfaceを共有していました。これからは、新しいawsvpcというネットワークモードを使うことで、Elastic Network Interfaceが直接タスクにアタッチされます。 これによってネットワークの設定を簡略化することができ、VPCが持っているネットワークの全機能、隔離性、そしてセキュリティの制御を各コンテナにEC2インスタンスと同様のレベルで利用することができます。 この記事では、awsvpcモードがどのように動作し、ECSのタスクでどのようにElastic Network Interfaceを使い始めることができるかをご紹介します。 背景: EC2のElastic Network Interface VPC内にEC2インスタンスを起動する時には、各インスタンスが互いに通信できるようにするために、追加のオーバーレイネットワークを設定する必要はありません。標準で、VPCのルーティングテーブルがインスタンスや他のエンドポイント間での通信をシームレスに実現してくれます。これは、Elastic Network Interfaceと呼ばれるVPC内の仮想的なネットワーク・インタフェースによって可能となっています。全ての起動されるEC2インスタンスは自動的に1つのElastic Network Interface(プライマリネットワークインタフェース)がアサインされます。サブネット、セキュリティグループといった全てのネットワークパラメータは、このプライマリネットワークインタフェースの属性として扱われます。 さらに、各Elastic Network Interfaceは作成時にVPCによってIPv4アドレス(プライマリIPv4アドレス)が割当られます。このプライマリアドレスはユニークでVPC内でルーティング可能なものです。これによって、VPCは実際はフラットなネットワークとなり、ネットワークトポロジを簡潔なものとしてくれます。 Elastic Network InterfaceはVPC上で多様なエンドポイントとの接続を実現するための基本的なビルディングブロックとみなすことができ、そのうえでより高レベルな抽象レイヤを構築することができます。これによってElastic Network Interfacdeは以下の機能を利用することが可能となっています: VPCネイティブなIPv4アドレスとルーティング (VPC上でのインスタンス間や他のエンドポイントとの間) ネットワークトラフィックの隔離 ACLとファイアウォールルール(セキュリティグループ)を使ったネットワークポリシーの強制 (サブネットのCIDRを通じた)IPv4アドレスレンジの強制 なぜawsvpcを使うのか？ 以前はECSはDockerが提供する標準のネットワークの挙動が提供するネットワーク機能に依存した形でコンテナ向けのネットワークスタックを構成していました。デフォルトのBridgeネットワークモードでは、インスタンス上のコンテナ達はdocker0ブリッジを使って互いにつながっています。インスタンス外のエンドポイントと通信する時には、コンテナはこのブリッジを利用し、それが実行されているインスタンスのプライマリネットワークインタフェースを使います。コンテナは、ファイアウォールルール(セキュリティグループ)やIPアドレスは、そのプライマリElastic Network Interfaceのネットワーク属性を共有しまた依存しています。 これは、Dockerによって割当られたIPアドレス(ローカルスコープのアドレスプールから割当られます)を使ってもこれらのコンテナに到達できないことと、細かいNetwork ACLやファイアウォールルールを強制できないことを意味します。代わりに、VPCからはインスタンスのプライマリElastic Network […]

Sam Dengler は、アマゾン ウェブ サービスのソリューションアーキテクトです。 このブログ記事では、チャットアプリケーションに関連する概念とアーキテクチャのパターンについて説明します。また、チャットクライアントとサーバーの実装の詳細、サンプルのチャットアプリケーションを AWS アカウントに展開する方法についても説明します。 背景情報 チャットアプリケーションを構築するには、クライアントがチャットルームの他の参加者に再配信されるメッセージを送信できる通信チャネルが必要となります。この通信は、一般に publish-subscribe パターン (PubSub) を使用して実装されます。このパターンでは、メッセージが中央トピックチャネルに送信されます。関係者は、このチャンネルをサブスクライブして更新の通知を受けることができます。このパターンでは､発行者の知識なしに受信者のグループを拡大または縮小できるように､発行者と受信者を切り離しています｡ PubSubは、クライアントが WebSockets を使用して通信するバックエンドサーバーに実装されます｡WebSockets は、クライアントとサーバー間で双方向にストリーミングされるデータのチャネルを提供する永続的な TCP 接続です。単一サーバアーキテクチャでは、1 つの PubSub アプリケーションが発行者と受信者の状態を管理し、WebSocket を介してクライアントにメッセージを再配布することもできます。次の図は、単一サーバー PubSub アーキテクチャ上の 2 つのクライアント間でメッセージが WebSocket を通過するパスを示しています。 単一サーバーアーキテクチャは､通信フローを説明するのに役立ちます｡しかし、ほとんどのソリューションビルダーはマルチサーバーアーキテクチャで設計したいと考えています。マルチサーバーアーキテクチャは、信頼性を高め、伸縮性を高め、クライアントの数が増えるにつれてアプリケーションを水平的に拡大するのに役立ちます。 マルチサーバーアーキテクチャでは、クライアントはサーバープールにトラフィックを転送するロードバランサーに対して WebSocket 接続を行います。これらのサーバーは、WebSocket 接続とそれを経由してストリーミングされるデータを管理します。WebSocket 接続が PubSub アプリケーションサーバーとの間で確立されると、その接続は永続化され、データは両方向のアプリケーションにストリームされます。ロードバランサーは、WebSocket 接続のリクエストを健全なサーバーに配信します。つまり、2 つのクライアントが異なるアプリケーションサーバーに WebSocket 接続を確立できます。   複数のアプリケーションがクライアントの WebSocket 接続を管理するため、アプリケーションはメッセージを再配布するためにそれらの間で通信する必要があります。この通信が必要なのは、メッセージが WebSocket を介して 1 つのアプリケーションサーバーにストリームアップされ、別のアプリケーションサーバーに接続されたクライアントにストリームダウンされる必要があるためです。クライアント接続を管理しているアプリケーションから PubSub ソリューションを外部に出すことで、アプリケーション間の共有通信の要件を満たすことができます。   次の図は、マルチサーバー PubSub […]

Matrix Analytics は人の命を救うために使われています。コロラド州のスタートアップ企業は肺結節と診断された患者の疾患の進行経過を追うために、アマゾン ウェブ サービス (AWS) でディープラーニングを使用しています。大方の場合、結節が良性でも慎重に監査したりフォローアップ治療を行うことは、結節が悪性腫瘍になった場合に重要な意味を持つことになります。 同社の設立者である Dr. Aki Alzubaidi 氏は、Glenwood Springs 病院に勤務していた時に見過ごされている患者が何人もいることに気付きました。患者の様子を把握するためのシステムは面倒な上にまとまりがなく、肺結節と診断された多くの患者が推奨されているフォローアップ治療を受けていないという、避けられるはずの粗末な結果を生み出していました。 がんリスクの予測と治療の管理 同社のフラッグシップアプリケーションである LungDirect は、初期のがん介入に二面性を持つアプローチを使用して悪性の危険性を予測したりフォローアップ治療を自動化しています。 まず、ディープラーニングのアルゴリズムを使用して構築した高度なコンピュータビジョン機能は、肺結節の悪性のリスクを結節の大きさや形、密度、容積、そして患者の喫煙年数、年齢、性別、人種などをもとに診断します。「放射線検査、臨床検査、個人的な臨床レベルでの変化など、臨床的な情報を考慮に入れ、病状について説明し次の対策に関する実用的な提案と管理方法を提供することが、ディープラーニングを利用する我々が目指すゴールです」と Dr. Alzubaidi 氏は述べています。 データに潜んでいるかもしれない非線形性クラスから成るがんリスクの診断を行うために、Machine Learning の 5 つのクラスを適用しています。こうした機能の 4 つのクラスは、一連のコンピュータビジョンアルゴリズムを使用してイメージから直接自動的に抽出されます。 がんの予測や診断を行うために、患者のスキャンを自動的に読み取れるツールを開発することは簡単ではありませんでした。けれども、Matrix Analytics は PoC (実証支援) を示すプロトタイプを素早く開発することができました。次に、当社のディープラーニングモデルを実装して、既存の論文で表示されている基準と比較しました。

Amazon ElastiCache では、高速なインメモリ型データストアおよびキャッシュを簡単にセットアップできます。ElastiCache は、最も人気のある 2 種類のオープンソースのソフトウェア (Redis および Memcached) をサポートしているため、要求の高いゲームのリーダーボードやインメモリアナリティクス、大規模なメッセージングのニーズに対応できます。 本日は、Amazon ElastiCache for Redis に追加された重要な機能についてご紹介します。最大 15 のシャードを作成して、それぞれに特定のスロットセットのキーと値を保存することができます (各クラスターの厳密なスロット数は 16,384 個)。1 つのクラスターで 3.55 テラバイトのインメモリデータを保存できると同時に、1 秒あたり 2,000 万回の読み取りと 450 万回の書き込みが可能です。 オンラインのサイズ変更 実行中の Redis 用 Amazon ElastiCache クラスターでシャード数を調整しながら、そのクラスターのオンライン状態を維持してリクエストに応答できるようになりました。これにより、クラスターをオフラインにしたり、空のキャッシュを使用しなくても、トラフィックやデータのボリュームの変更に対応することができます。また、シャード数を変更せずに、実行中のクラスターを再分散してスロットスペースを均一に再配置することもできます。 リシャーディングオペレーションまたは再分散オペレーションを開始すると、Redis 用 ElastiCache は、クラスターのシャード間でスロットが均等分散されるように計画の準備を開始します。その後、シャード全体にスロットを転送し、効率性を重視して並列的に多数のスロットを移動します。これは、クラスターでリクエストに応答する場合に行われ、送信時のスロットへ書き込む書き込みスループットが少し上がります。移行率は、インスタンスタイプ、ネットワーク速度、スロットへの読み込み/書き込みトラフィックによって異なり、通常 1 分あたり約 1 ギガバイトです。 リシャーディングオペレーションと再分散オペレーションは、クラスタモードを有効にして作成された Redis クラスターに適用されます。 クラスターのリシャーディング 一般的に、大幅なメモリプレッシャーの問題に直面したり、個々のノードがボトルネックになった場合は、リシャーディングでクラスターを拡張します。クラスターの CloudWatch メトリクスを監視すれば、以下のような状況を識別できます。 メモリプレッシャー – FreeableMemory、SwapUsage、BytesUsedForCache。 CPU ボトルネック […]