Amazon Web Services ブログ

こんにちは、テクニカルソリューションアーキテクトの金澤 (@ketancho) です。 3月も最終日ですね。明日から新生活が始まる！という方も多いのではないでしょうか？本日はそんな「この春からエンジニアデビューです！」という方向けに、先日公開した “AWS のはじめの一歩を後押しする” ハンズオンを紹介いたします。 AWS Hands-on for Beginners シリーズ一覧 前回の記事: サーバーレスハンズオン第3弾 “AI サービスを活用した音声文字起こし＆感情分析編” を公開しました！- Monthly AWS Hands-on for Beginners 2020年2月号   AWS Hands-on for Beginners とは？ AWS Hands-on for Beginners は、動画にそって実際に手を動かしながら AWS サービスについて学んでいただく無償のコンテンツです。名前の通り、初めて AWS サービスをご利用される方向けの内容ですので、学習の最初のステップとしてご活用いただけます。オンデマンド形式での配信となるので、移動時間などのスキマ時間での学習もできますし、分かりにくい部分を巻き戻して何度でもご覧いただくことができます。   [New] “ハンズオンはじめの一歩: AWS アカウントの作り方 & IAM 基本のキ” を公開しました 3/25(水) に AWS Hands-on for Beginners “ハンズオンはじめの一歩” 編を公開しました。このハンズオンでは、 […]

農林水産省（以下「農水省」）様より、”「デジタル地図」を活用した農地情報の管理に関する検討会』取りまとめ”　が公開されました（2020年3月下旬公開、以下「取りまとめ」）。2019年秋以降、本検討会へはAWSメンバーも参加して各種の提言を行って参りました。以下、AWSパブリックセクターより、本「取りまとめ」の意義や要点を解説しながら、農林水産政策分野やデジタル地図に関連するAWSのサービスや事例をご紹介させていただきます。   ❖「デジタル地図」検討会設置の目的 農水省では、現状の”農地情報は各施策の実施機関ごとに個別に収集・管理されている”こと、つまりは情報が散在していることに起因し、 １）農業者は、同様の情報でも実施機関ごとに個別に申告、 ２）実施機関ごとに、農地情報を独立したデータベースで管理、 ３）現地確認も実施機関ごとに実施しているため、情報の整合性を保つための突合作業等は大きな負担となっており、また、整合性が取れていないケースもあるといった状態 ────といった問題があることを特定しました。 これらの問題意識から出発し、農水省DX室は今回の「デジタル地図」を活用した農地情報の管理に関する検討会の設置を決め、約半年間に渡り活動を重ねてきました。この、先進技術と政策の融合を目指した取り組みに関しては、「農地情報をデジタル地図に 農水省が一元化」と題して日経新聞など各種メディアでも報じられていたところです。 検討会での主な論点となったのは、「農地情報の一元的な管理を可能とする技術的環境が整備されつつある」なか、いかにして「農地情報の正確性と整合性を確保しつつ、農業者や実施機関等の関係者の負担軽減を図ることができる」か──という点です。特に、「幅51cmもの、農地転用に関する分厚い書類」「2,136時間＆57,300枚が、経営所得安定対策の申請受付等に費やされる」「7,200経営体が22,000筆のデータを個別にPDF化し打ち込み」といった全国の農業関係者が直面する困難がデータポイントで列記される「第２章 現状と課題」は圧巻です。 これらの負担を先端技術により解決することを目指した本検討会においては、クラウドを活用することで高水準で実現することができる”拡張性”・”信頼性”・”柔軟性”・”堅牢性”・”可用性” 等の観点から整理をいただき、”システムの構築・運用に当たっての原則”として記載をいただいております。詳しくは、「取りまとめ」の“第5章 デジタル地図のシステム要件”をご参照ください。 (参考) ↓：「取りまとめ」文書中の、システムの構築・運用の原則 こうした方向性のもと取りまとめられた今回の農水省DX室のイニシアティブが、以下サイトにてプレスリリースされました： ”「デジタル地図」を活用した農地情報の管理に関する検討会』取りまとめについて”   ❖ AWSからの提言：クラウドが「デジタル地図」の有効活用を加速する 農水省の「取りまとめ」には、幾つもの政策的・技術的に踏み込んだ内容が記載されており、以下のとおりAWSからの提言と合致する論点も盛り込まれています： オンプレからクラウドへの転換：「従来のオンプレミス［・・中略・・］では、限られたネットワーク内でしかGIS[注：地理情報システム]上の地図情報の閲覧、編集ができなかったが、クラウドベースのGISを活用することにより、インターネット接続による地図情報の閲覧、編集が格段と容易になる」との記載にて、クラウドベースでの技術のメリットを明記いただいています。　”地図”に関連し、DX室にも紹介させていただいた、高精度地図データ配信にAWSの機械学習モデルを活用した株式会社ゼンリンデータコム様の事例に関しては、こちらをご覧ください。 拡張性の高いデータベース：「データベース管理については、将来的なデータ項目の追加や、レコード数やアクセス数の増大等によるアクセス速度の低下防止に対応できるようにすることが重要であるが、データ項目の柔軟な加除やシステムの高速化を可能とするNoSQL等の新しいデータベース管理手法も活用可能となってきている」との記載にて、新型のDBMS採用を模索する方向性を明記いただいています。NoSQLデータベースを含む、AWSのデータベースサービスの全容に関してはこちらをご参照ください。 超大規模データのオープン化：「国や地方自治体において、様々なデータをリアルタイムで集約し、データに基づいた多元的な分析を行うことで、農業施策に反映させることで、課題の的確な把握・対応を可能とする。また、集約されたデータをオープン化することで、研究機関等による多様なデータ分析に基づいた政策提言を容易にする」との記載にて、オープンデータ化の方向性を明記いただいています。オープンデータを加速するAWSの取り組みに関してはこちらをご覧ください。特に、公的機関向けにストレージ費用をAWSが負担する「AWS Public Dataset Program」は現在、「衛星画像」「地理情報」「気候」等のカテゴリーを設け、NOAA（アメリカ海洋大気庁）等が収集した、合計で120を超えるDatasetを公開しております（2020年3月現在）。 パブリッククラウドとLGWANとの接続：「地方自治体においては関係業務がLGWAN環境で行われる一方、現場におけるインターネット環境でのタブレット等による農地情報の閲覧、編集のニーズがあることを踏まえ、LGWANとインターネットのハイブリッド方式を採用」「LGWANとパブリッククラウドの接続のあり方に関しては現在総務省において検討が進んでおり、その結果を踏まえ、必要な検討を行う」との記載にて、農業関係者皆様にとっての高い利便性確保のための整理が待たれる旨、明記いただいています。 AWSは、クラウドが次世代の農業をサステナブルかつ、魅力的な産業へと進化させていくことに強くコミットしています。自身も農業の盛んな米国ケンタッキー州の出身であると回顧することから始まるテレサ・カールソン（AWS Worldwide パブリックセクターのバイスプレジデント）のブログも併せてご参照ください：”Mission: Technology-enabled, sustainable agriculture”。   ❖ 提言させていただいたAWSのサービス 今回の農水省の検討会では、以下のAWSサービスが特に「デジタル地図」の構想と親和性が高いものと判断し、提言に盛り込ませていただきました。 データレイク構築の要となる“Amazon S3(Simple Storage Service)”：様々なデータを分析し正しい意思決定を行うためには、規模にかかわらず、全ての構造化データと非構造化データを長期間、安全に保存することが可能な「データレイク」を構築する必要があります。Amazon S3を活用いただくことが、圧倒的低コストでのデータレイク構築のための近道です。 軌道衛星からのデータを受信する “AWS Ground Station”：天気予報、地表画像撮影、通信、放送など軌道衛星からのデータを、独自の地上基地局を管理することなくご活用いただけます。AWS Grand Stationで受信されたデータは、AWSグローバルインフラストラクチャ（世界規模の低遅延ファイバーネットワーク）を経由し、Amazon S3等へ蓄積し利活用が可能です。 Amazon DynamoDBなど多種多様なデータベース：データ処理を高速、低コストで実現するためには、アプリケーションや利用ユースケースに最適なデータベースを無理なく選択する必要があります。AWSが提供しているデータベースは、一般的な利用ユースケースをほぼ網羅するデータベースが7分類あり、AWS上で簡単に相互連携することで、高速、低コストなデータ処理を実現可能です。 ”Amazon […]

AWS Game Techでは、各イベントなどを通じてゲーム開発環境のクラウド化についてご紹介してきました。これまでゲーム開発に利用されるバージョン管理やビルドの実行のためのハードウェアはプロジェクトの初期に購入し、オフィスやデータセンターに設置されることが一般的でしたが、ゲーム開発の高度化・複雑化にともない、事前にサーバやストレージなどの容量を予測することが難しくなり、追加の調達にも時間がかかるなどの課題が顕在化しています。このようは背景から、いつでも必要なときに必要なだけ従量課金で利用できるクラウドをゲーム開発に活用する動きが高まっています。 実際にUnreal Engine4やUnity、自社製ゲームエンジンのビルドパイプラインを中心に多くのお客様からお問い合わせをいただいていますが、今回はそのビルドパイプラインを中心に、AWS上でどのようにゲーム開発環境を構築するか、それぞれユースケース別にご紹介します。全体像はこちらです。   AWSではVPC(Virtual Private Cloud)を利用してさまざまな要件に応じてネットワーク環境を構成できます。今回はそのVPCを利用して、 VPCを作成し、そのVPCにはインターネットから直接アクセスできるパブリックサブネット、VPC内やオフィス/データセンターからのネットワーク接続のみしか受け付けないプライベートサブネットも作成します。 インターネットから直接接続できるサブネット上にUnreal Engine4クライアントを構築し、NICE DCVと言われるリモート接続ソフトウェアを利用してご自宅などから利用できる開発環境を構成します。 アセットやプログラムのバージョン管理のためにPerforce社のHelix Coreを利用し、AWSのVPC上にマスター/コミットのサーバを構成します。 ご自身のデータセンターやオフィスとAWSのVPCとのネットワーク接続のためにVPNで接続します。 また、その他にデザイナーやプロデューサーの方々向けにAmazon WorksSpacesによる仮想デスクトップ環境の構築についても簡単にご紹介します。 事前準備 環境構築にあたり、以下を事前に準備してください。 拠点側のVPN用固定IPアドレス オフィス/データセンターなどの拠点とのVPN接続を行う場合は、拠点側のVPNルータのパブリック固定IPをネットワーク担当者の方にご確認ください。 AWS側で利用するネットワークアドレス AWSとのネットワーク接続を実施するにあたり、AWS側で利用できるネットワークアドレスもご準備ください。実際にこのネットワークアドレスを利用するVPCでは/28ネットマスク(16個のIPアドレス)が最小ですが、リソース拡張に備えて/24以上の大きめのネットマスクをご利用いただくことをお勧めします。拠点と接続するときは拠点ですでに利用しているアドレスと被らないネットワークアドレスをご利用ください。 VPCでAWS上にネットワーク環境を作成 まず事前準備として、AWS上で利用できるネットワーク環境を作成するために、VPCおよびVPCの中で利用できるネットワークであるサブネットを構成します。このサブネットの中にサーバやクライアントが起動する形となります。サブネットにはインターネットとの接続性によってパブリック/プライベートの2種類を作成することができますが、インターネット側から直接接続を受け付けないものでない限りはプライベートサブネットの中でサーバなどを起動することを強くお勧めします。今回ご紹介する開発ワークステーションは外部から直接ネットワーク接続するケースを想定しているため、パブリックサブネットも作成します。 AWSのマネージメントコンソールで画面右上の東京リージョンを選択し、AWSのサービス検索でVPCを選択します。 次のステップ２では、事前準備で用意したAWS側で利用するネットワークアドレスを入力します。AWSで利用する全体のネットワークを“IPv4 CIDRブロック”に入力、パブリックサブネット/プライベートサブネットの２つをそれぞれ全体のネットワークから切り出します。今回は10.0.0.0/16をAWS全体で利用できるネットワークアドレスとし、その中からパブリックサブネットを10.0.0.0/24、プライベートサブネットを10.0.1.0/24として設定しています。また、VPC名には任意の名前を入力します。 最後のステップ３で拠点とのVPN設定を行います。 カスタマーゲートウェイIP： 事前準備で用意した拠点側ルータのパブリックIPアドレスを入力 カスタマーゲートウェイ名： 任意の名前を入力 VPN接続名： 任意の名前を入力 ルーティングの種類： 静的　（BGPも選択できますが、今回は設定が簡単な静的ルーティング設定を行います。) 入力が完了したら[VPCの作成]をクリックします。 数分後、以下の画面が表示されればVPCの作成が完了です。   ゲーム開発環境の構築とリモート接続 普段はオフィスにあるご自分のPC上でゲームエンジン(Unreal Engine4)でゲームを開発しているケースを想定し、この環境をAWS上でどのように実現するかについてご紹介します。まずGPUマシンについては、AWSが提供するGPUインスタンスを利用することができます。2020年3月時点で最も新しいものはNVIDIA T4 Tensor Core CPUを搭載したG4インスタンスで、東京リージョンでもご利用になれます。 また、今回利用するNICE DCV(Desktop Cloud Visualization) はネットワーク経由で2D/3Dのインタラクティブアプリケーションへのリモートアクセスを提供します。AWS上であれば追加コストなしでEC2インスタンス上で使用できます。 リモート接続はNICE DCV以外に以下のようなソリューションがありますが、機能別の比較は以下のようになります。NICE […]

2020年3月10日 から開催している「AWS Innovate」をお楽しみいただいていますでしょうか？ AWS Innovate はグローバルでも人気のある「クラウド活用のための無償オンラインカンファレンス」です．今回は 2020年3月10日 から 2020年4月17日 までの「計39日間」毎日開催をしており，「計42個のセッション」を何度でも視聴可能です．参加申込みは簡単です！以下の申込みサイトにアクセスをしましょう． AWS Innovate サイト AWS Innovate 申込みサイト（無料）   「AWS Innovate 2020 の見どころ」を紹介する連載も3週目となりましたが，いよいよラストです！本記事も AWS テクニカルトレーナーの吉田慶章が担当します．今までの連載では「基調講演」と「ハンズオン」を紹介してきましたが，まだまだ見どころはあります．本記事では，全セッションを紹介したい気持ちを抑えつつ，オススメをピックアップして，紹介します！今までの連載もあわせて読んでいただけると嬉しいです． AWS Innovate 2020 : 今年もスタート！ | Amazon Web Services ブログ AWS Innovate 2020 : ハンズオンセッションで実践力を高めよう！ | Amazon Web Services ブログ   見どころ : クラウドで信頼性の高いシステムを構築するための障害や故障との向き合い方 まず最初に紹介するのは「クラウドで信頼性の高いシステムを構築するための障害や故障との向き合い方 (Lv.200)」です．皆さんは「Everything fails all the time」という Amazon CTO […]

先日 (2020/03/18) 開催しました AWS Black Belt Online Seminar「Amazon Redshift」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200318 AWS Black Belt Online Seminar Amazon Redshift from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. どういった場合に行指向ストレージが向いているのでしょうか？（逆に言えば、Redshiftでの処理に向いていないクエリはあるのでしょうか） A. 多数のショートトランザクションが中心となるような場合に行指向ストレージが向いていると言えます。例えば、特定の行のみの情報を取得するような場合や、1行に対する更新処理や挿入処理が繰り返し行われることが多いシステムの場合、行指向ストレージが向いていることが考えられます。一般論になりますが、いわゆるOLTPの処理は行指向の方が向いていると言えます。一方で、比較的少量のトランザクションが中心で、クエリが多くの場合複雑で大規模な履歴データセットに対する集計を伴うような場合、Amazon Redshiftが向いていると言えます。AWSでは、目的別に応じて多様なデータベースをご用意しておりますので、利用シーンに合わせて選択いただければと思います。 Q. SQAにもスロットという概念あるのでしょうか？ A. はい、SQAにもスロットという概念があります。SQA用のキューがデフォルトで存在し、該当のキューに対して、スロットが設定されています。Amazon Redshiftがクエリを実行する際には、必ず、デフォルトキュー、ユーザー定義のキュー、SQA用のキューいずれかが持つスロットが使用されることになります。ただし、SQA用のキューが確保しているメモリ容量やスロットの数については公開されておりません。 — 今後の AWS Webinar | イベントスケジュール 直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。 皆様のご参加をお待ちしております。 — AWS Innovate Online Conference / AWS Startup Day Online 【全42セッション公開中】 […]

Battlesnake は、従来のスネークゲームを基礎にした AI コンペティションで、複数の AI を搭載したスネークが生き残りをかけて競います。Battlesnake は、あらゆるレベルの開発者のコミュニティを魅了しています。何百ものスネークが競い合い、オンラインの Battlesnake グローバルアリーナでランキング上位に入ることを目指します。Battlesnake はまた、1,000 人以上の開発者と非開発者が参加するオフラインイベントを開催しており、その様子は Twitch でストリーミング配信されています。開発者のチームは、コンペティションのためにスネークを作り、新しい技術スキルを学び、協力することを学び、楽しんでいます。チームは、最先端の深層強化学習 (RL) アルゴリズムから独自のヒューリスティックベースの戦略まで、さまざまな戦略を駆使してスネークを構築できます。 この記事では、Amazon SageMaker を使用して RL ベースのスネークを構築する方法を説明します。 従来のスネークゲームでは、スネークを上下左右に移動するようにコントロールします。スネークが壁、別のスネーク、またはスネーク自身の体にぶつかると、スネークは死にます。スネークが食物を食べると、体が長くなります。従来のスネークゲームと比べると、Battlesnake にはいくつか違う点があります。まず、スネークを制御するのは、プログラムです。2 頭のスネークが正面衝突すると、小さいスネークが死にます。また、飢えメカニズムがあります。100 手動いて食物を食べられなかったスネークは死にます。そのため、生存率を最大にする、他のスネークを積極的に攻撃する、または他のスネークを避けようとすることはすべて、プレイヤーが採用している実践的な戦略です。スネークはプログラムされたウェブサーバーとして実装され、Battlesnake エンジンはゲームの現在の状態を考慮して次の動きをクエリします。詳細については、Battlesnake ウェブサイトの「開始方法」を参照してください。 この記事では、SageMaker Battlesnake スターターパックを使用して、スネークの構築に必要な時間と労力を節約する方法を示します。SageMaker Battlesnake スターターパックは、RL でトレーニングされた AI 搭載のスネークを提供します。スターターパックは、独自の RL ポリシーと、RL アルゴリズムの上にカスタムヒューリスティックベースのルールを構築するツールをトレーニングするための環境も提供します。さらに、AI ボットをデプロイおよびホストするウェブインフラストラクチャが自動的に生成されます。SageMaker Battlesnake スターターパックでは、周囲のインフラストラクチャを気にすることなく、AI の開発に集中できます。 Amazon SageMaker Battlesnake スターターパックは、AWS CloudFormation の quick-create リンクを使用します。これにより、GitHub repo から AWS マネジメントコンソールへ 1 クリックデプロイを行えます。スタックを作成すると、次の […]

Amazon SageMaker を使用して、組織は機械学習モデルを構築、トレーニング、およびデプロイできます。コンシューマー向けの組織は、パーソナライズされた製品の推奨事項を作成したり、顧客の好みに基づいてアプリケーションの動作を自動で調整したりすることにより、顧客体験を豊かにすることができます。そのようなアプリケーションを構築する場合、コンシューマーデバイスで実行されているクライアントソフトウェアでランタイム推論エンドポイントを使用可能にする方法は、アーキテクチャ上の重要な考慮事項の 1 つです。通常、エンドポイントは、クライアントソフトウェアに一連の完全なアプリケーション機能を提供する REST など、ウェブ上で使いやすい従来のアプローチに基づいて、より広範囲な API の一部として提供されます。 Amazon API Gateway は、開発者があらゆる規模の API を簡単に作成、公開、保守、監視、保護できるようにするフルマネージド型サービスです。API Gateway を使用して、Amazon SageMaker エンドポイントの外部に面した単一のエントリポイントを提示できます。これには、次の利点があります。 クライアント向けの REST API と、基となる Amazon SageMaker ランタイム推論 API の間を変換することにより、基本実装仕様からクライアントを隔離 クライアントリクエストの認証と承認をサポート 調整、評価制限、およびクォータ管理を使用してクライアントリクエストを管理 AWS WAF が提供するファイアウォール機能を使用 キャッシングとリクエストの検証により、コスト削減と運用の最適化を実現 モデルの変更を安全に導入するためのカナリアデプロイメントを簡単に作成 この記事では、マッピングテンプレートと呼ばれる API Gateway 機能を使用して、REST API の一部として Amazon SageMaker 推論エンドポイントを処理する方法をお見せします。この機能により、REST API を Amazon SageMaker ランタイムエンドポイントに直接統合できるため、エンドポイントを呼び出すための中間コンピューティングリソース (AWS Lambda または Amazon ECS コンテナなど) […]

AWS では、ネットワーク、コンピューティングリソース、またはオブジェクトストレージなどのクラウドサービスの管理とアクセスを簡略化するために、最新の仮想テクノロジーの構築を得意としています。 あるリレーショナルデータベース管理システム (RDBMS) では、1 つのビューはテーブルに適用された仮想化であり、データベースクエリの結果を表す仮想テーブルと言えます。ビューはスキーマの設計時によく使用されます。データのサブセット、要約されたデータ (集約または変換されたデータ) の表示、または複数のテーブル間でのデータアクセスの簡略化などがその用途です。Amazon Redshift などのデータウェアハウスを使用すると、1 つのビューで、Amazon QuickSight または Tableau などのビジネスインテリジェンス (BI) ツールの複数のテーブルからの集約データへ簡易的にアクセスできるようになります。 ビューによって使いやすさや順応性は高まりますが、データアクセスのスピードは落ちます。データベースシステムはアプリケーションがビューにアクセスするたびに、ビューを示す基盤となるクエリを評価しなければならなくなります。パフォーマンスが重要な場合、データエンジニアはその代替手段として、create table as (CTAS) を使用します。CTAS はクエリで定義されたテーブルです。このクエリはテーブルの作成時に実行され、アプリケーションは通常のテーブルとしてそれを使用できます。これの不便なところは基盤となるデータが更新されたときに、CTAS のデータセットは更新されないことです。さらに、 CTAS の定義はデータベースシステム内に保存されません。そのため、テーブルが CTAS によって作成されたかを知ることは不可能で、どの CTAS を更新する必要があるか、どれが最新かを追跡するのは困難になります。 今日は、Amazon Redshift の マテリアライズドビューをご紹介します。マテリアライズドビュー (MV) はクエリのデータを含むデータベースオブジェクトです。マテリアライズドビューはビューのキャッシュのようなものと考えられます。実行時にデータセットを構築、計算する代わりに、マテリアライズドビューはビューを作成した時点で計算を事前に実行し、データアクセスを保存および最適化します。データは通常のテーブルデータと同様に、クエリに使用できます。 分析クエリでマテリアライズドビューを使用すると、クエリの実行時間を桁違いに短縮できます。その理由はマテリアライズドビューを定義するクエリが、すでに実行済みで、データがデータベースシステムで利用できる状態になっているためです。 マテリアライズドビューは予測可能で何度も繰り返し実行できるクエリで特に便利です。大きなテーブルにリソースをたくさん使うクエリを実行する代わりに、アプリケーションはマテリアライズドビューに保存された計算済みのデータに対してクエリを実行できます。 ベーステーブルのデータが変動するときは、Redshift の SQL ステートメント “refresh materialized view“ を実行して、マテリアライズドビューを更新します。更新ステートメントの実行後、マテリアライズドビューには通常のビューで返されたのと同等のデータが含まれます。更新は増分のみ、または完全更新 (再計算) のいずれかになります。可能な場合、Redshift はマテリアライズドビューが最後に更新されてからベーステーブルで変更のあったデータのみを増分更新します。 それでは、その仕組み見てみましょう。販売情報を格納するためにサンプルスキーマを作成します。販売情報は販売トランザクションと商品が販売された店の詳細情報で構成されています。 都市別販売金額合計を表示するために、create materialized view SQL ステートメントを使用して、マテリアライズドビューを作成します。Redshift […]

本番アプリケーションを移行する場合、多くの場合、フォールバックオプションを備えていることが重要です。このブログ記事では、グローバルトランザクション識別子 (GTID) ベースのレプリケーションを使用して、Amazon RDS MySQL ワークロードを Amazon Aurora MySQL に移行する方法を説明します。また、問題が発生した場合にフォールバックメカニズムを使用する方法についても説明します。 GTID ベースのレプリケーションの詳細については、「Amazon Aurora for MySQL 互換エディションでグローバルトランザクション 識別子 (GTID) によるレプリケーションがサポートされるようになりました」をご覧ください。 この記事では、レプリケーショントポロジには、2 つのリードレプリカ (RDS MySQL リードレプリカと Aurora MySQL レプリカ) を持つマスター RDS MySQL インスタンスがあります。移行中に問題が発生した場合のフォールバックインスタンスとして RDS MySQL リードレプリカを使用し、元の RDS MySQL マスターが影響を受けないようにします。ただし、元の RDS MySQL マスターインスタンスをフォールバックオプションとして使用することもできます。移行が成功すると、Aurora MySQL レプリカが RDS MySQL レプリカインスタンスのマスターインスタンスになります。 GTID ベースのレプリケーションを使用する主な利点は、すべてのトランザクションに一意の識別子を割り当てられ、レプリケーショントポロジ内の各 MySQL サーバーがすでに実行したトランザクションを追跡できることにあります。GTID ベースのレプリケーションはトランザクションベースであるため、マスターとレプリカ間のデータの一貫性を簡単に判断できます。マスターでコミットされたすべてのトランザクションがレプリカにもコミットされている場合、2 つの間に一貫性があります。これにより、auto-positioning が可能になります。これは、binlog ファイルの名前または位置を指定することなく、レプリカがマスターインスタンスをポイントする機能です。 前提条件 このチュートリアルを実行するには、次の前提条件を満たしている必要があります。 […]

インメモリデータストアは、アプリケーションのスケーラビリティのために広く使用されており、開発者は、頻繁にアクセスされる (揮発性または永続的) データを保存することの恩恵を長年にわたって享受しています。Redis のようなシステムは、データベースとバックエンドを着信トラフィックから疎結合化し、本来ならそれらに到達するはずだったほとんどのトラフィックを排し、ユーザーのアプリケーションレイテンシーを削減するのに役立ちます。 これらのサーバーを管理することが重要なタスクであることは明白で、何が起きようとも、それらを維持し、実行し続けるために細心の注意を払わなければなりません。以前の業務において、私のチームは、物理キャッシュサーバーのクラスターをホスティングスイート間で移動する必要がありました。1 つずつ外部バッテリーに接続し、外部電源プラグを抜き、それらをラックから取り出し、オフィス用の台車 (!) で他のスイートまで運び、再びそれらをラックに入れていたのです! サービスを中断することなく実行できましたが、これが完了すると私たち全員は安堵のため息をつきました。高トラフィックのプラットフォームでキャッシュデータを失うと、大変なことになるからです。そのことを考えれば羨ましい限りです。幸いなことに、クラウドインフラストラクチャはより柔軟です! インシデントが発生した場合のサービスの中断を最小限に抑えるために、Memcached および Redis のマネージドインメモリデータストアである Amazon ElastiCache に、クラスターモード、自動フェールオーバーを備えたマルチAZなど、多くの高可用性機能を追加しました。 Redis は多くの場合、低レイテンシートラフィックをグローバルユーザーに提供するために使用されることから、お客様は、AWS リージョンをまたいで Amazon ElastiCache クラスターをレプリケートできるようになることを望んでいます。当社はこれらに耳を傾け、解決に向けて動きました。そして本日、このレプリケーション機能が Redis クラスターで利用可能になったことをお知らせできることを大変嬉しく思います。 Amazon ElastiCache Global Datastore For Redis の紹介 簡単に言えば、Amazon ElastiCache Global Datastore for Redis を使用すると、1 つのリージョンのクラスターを最大 2 つの他のリージョンのクラスターに複製できます。お客様は、通常、次の目的でこれを行います。 ネットワークレイテンシーを削減し、アプリケーションの応答性を向上させるために、キャッシュされたデータをユーザーの近くに置く。 リージョンの一部または全部が完全に利用できない場合に備えた災害復旧機能を構築する。 グローバルデータストアのセットアップは非常に簡単です。最初に、アプリケーションから書き込みを受信するプライマリクラスターとしてのクラスターを選択します。これは、新しいクラスター、または Redis 5.0.6 以降を実行する既存のクラスターのいずれかにすることができます。次に、他のリージョンにプライマリから更新を受信する最大 2 つのセカンダリクラスターを追加します。 このセットアップは、単一ノードクラスターを除くすべての Redis 設定で使用できます。もちろん、単一ノードクラスターをレプリケーショングループクラスターに変換し、それをプライマリクラスターとして使用できます。 最後に重要なことですが、グローバルデータストアの一部であるクラスターは、通常どおりに変更およびサイズ変更できます (ノードの追加または削除、ノードタイプの変更、シャードの追加または削除、レプリカノードの追加または削除)。 簡単なデモを見てみましょう。 […]