Amazon Web Services ブログ

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

開発を迅速化し、その品質を高めるには、アプリケーションのコード変更を管理してデプロイする継続的なデリバリー戦略を使用することができますが、データベース移行のための継続的デリバリーは、手動プロセスであることがほとんどです。 データベース移行のための継続的インテグレーションと継続的デリバリー (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

Amazon Forecast が一般公開されました

履歴データを基に正確な時系列予測を得るのは、たやすい作業とは言えません。当社は昨年の re:Invent において Amazon Forecast を発表しました。これは、機械学習についてまったく経験がない人でも高い精度の予測をすることができる、完全マネージド型のサービスです。 その Amazon Forecast が一般公開されたことを、本日お伝えできるのは非常に喜ばしいことです。 Amazon Forecast では、サーバーのプロビジョニングは必要ありません。 これに必要なのは、履歴データ、そして予測結果に影響がありそうなメタデータを追加で揃えることだけです。たとえば、入手するか製造しようとしている特定の製品に関する需要は、天候、季節、そしてその製品が使用される土地などにより、おそらく変わってくるでしょう。 Amazon Forecast は、Amazon で使われているものと同じテクノロジーをベースにしており、スケーラブルで高い精度を持つ予測技術を使いやすく構築および運用するための、長年の経験を詰め込んだものとなっています。これは複数のデータセットを基に深層学習 を行い、多様なアルゴリズムを自動的に切り替えて使用するので、製品需要、クラウドのコンピューティング使用量、財務計画、サプライチェーン管理システムでのリソース管理など多くのユースケースに対応できます。 Amazon Forecast を使ってみる 今回の記事では、いくつかのサンプルデータを利用します。興味深いユースケースが良いので、今回はUCI の機械学習レポジトリが提供する、個別家庭の電力消費データセットを使うことにします。作業を簡単にするため、時間ごとのデータが CSV 形式のファイルに集められたバージョンを使っていきます。次に示すのはこのデータの最初の数行で、ここにはタイムスタンプ、電力消費量、クライアント ID が記述されています。 2014-01-01 01:00:00,38.34991708126038,client_12 2014-01-01 02:00:00,33.5820895522388,client_12 2014-01-01 03:00:00,34.41127694859037,client_12 2014-01-01 04:00:00,39.800995024875625,client_12 2014-01-01 05:00:00,41.044776119402975,client_12 それでは、Amazon Forecast コンソールを使いながら、予測子の構築と予測値の取得がいかに簡単かを確かめてみましょう。より進んだユーザーのためのオプションは、Jupyter ノートブックと AWS SDK for Python から利用できます。この GitHub レポジトリにサンプルのノートブックがいくつかあります。 Amazon Forecast コンソールで先ず最初に行うステップは、データセットグループの作成です。データセットグループは、お互いに関連のあるデータのためのコンテナーとして機能します。 データセットグループに合わせて、[Forecasting domain] から一つを選択します。各ドメインは、小売り、在庫計画、ウェブのトラフィックなど、それぞれ特定のユースケースに対応しています。また、そのトレーニングに使われたデータ形式を基にしたデータセットタイプを使用します。今回は、帰属するカテゴリーがないすべてのユースケースをカバーしている、[Custom] ドメインを使用しましょう。 次に行うのは、データセットの作成です。今アップロードしようとしているデータは時間ごとに集められたものですので、[Frequency […]

Read More

SQL Server 2012 および 2016 での SQL Server Reporting Service 2016 の設定

 SQL Server Reporting Services (SSRS) への接続試行は、「Reporting Services インスタンスが見つかりませんでした」というエラーで失敗することがあります。 このエラーは、SSRS、SQL Server Integration Services (SSIS)、および SQL Server Analysis Services (SSAS) でインストールされた Amazon Machine Images (AMI) を使用するときに発生する場合があります。 この記事では、これらのエラーを避けるために SQL Server 2016 で SSRS 2016 を設定する方法のステップバイステップ手順を説明します。 エラーを確認する まず、SSRS が開始されたことを確認します。 関連する AMI を使用して Amazon EC2 インスタンスを起動します。 services.msc コンソールに移動します。これは 2 つの方法のいずれかを使って実行できます。 [ファイル名を指定して実行] から services.msc に入る。 SQL Server 構成マネージャーを使用する。 SQL Server […]

Read More

AWS DMS を使ってデータベースの移行とリフレッシュ処理を自動化する

アプリケーション開発者やシステム管理者は、データの移行、更新、マスクなどの目的で、データストア間での複製を行うことがあります。事前調査、スキーマ変換、スクリプト変換、データ移行、機能試験、パフォーマンスのチューニング、その他のタスクが伴うデータ複製作業は、多くの組織にとって複雑で複数のフェーズが必要な作業となります。そのため、データ複製をサポートするいくつものツールが存在します。 AWS Database Migration Service (DMS) は、データベースを AWS に迅速かつ安全に移行するためのツールです。ソースのデータベースは移行処理中でも完全な機能を維持するので、アプリケーションの中断時間を最小にできます。AWS DMS を利用すると、オープンソースで広く使われている商用データベースとの間で、双方向のデータ移行が行えます。 同種間および異種間、両方の移行をサポートする AWS DMS では、高い可用性を維持したまま、データストア間でのデータ複製を持続的に実行できます。AWS DMS では、全ロードで変更がキャッシュされたデータを、データストア間で継続的に複製できます。 今回の記事では、グローバルなデータの移行や更新、マスキングを自動で行うソリューションをご紹介していきます。このソリューションでは、DMS、AWS Lambda、Amazon CloudWatch リソースなどを統合しながら、AWS CloudFormation スタックをデプロイします。DMS のレプリケーションタスクが、オンプレミスから AWS Cloud 上にあるデータストアへのデータ移行もしくは更新を行います。 今回のデモでは、オンプレミス側のデータベースとしては Amazon RDS for Oracle DB インスタンスを使い、クラウドデータベースとしては Amazon Aurora MySQL インスタンスを使います。DMS のイベントサブスクリプション機能を有効にしておくと、DMS のレプリケーションタスクはすべてのタスクイベントを、Amazon SNS トピックを使い通知するようになります。この SNS トピックは、サブスクライブした Lambda 関数へ通知されます。この Lambda 関数が CloudWatch Events のルールを有効化もしくは無効化した後、DMS のレプリケーションタスクをトリガーします。 ネットワーク上の問題を簡素化するため今回のソリューションでは、すべてのサポートサービスを 1 つの […]

Read More