Amazon Web Services ブログ

Category: Database

Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行するベストプラクティス: 移行プロセスとインフラストラクチャに関する考慮事項

AWS クラウドで Oracle から PostgreSQL に移行するプロセスは何段階もあって複雑になりがちです。評価ステージから切り替えステージまで、さまざまなテクノロジーとスキルが必要になります。このブログシリーズでは、ソースの Oracle データベースとターゲットの PostgreSQL サービス、そして AWS Database Migration (AWS DMS) サービスについて、その環境と構成の設定方法をお伝えしています。特に焦点を当てているのが、ソースおよびターゲットデータベースのインフラストラクチャと設定、そして開発からテスト、本稼働、ステージングデータベースまでの各環境の移行に使用するツールと構成です。まずは、Oracle から、PostgreSQL との互換性がある Amazon RDS for PostgreSQL または Amazon Aurora ベースのデータベースへのデータ移行から始めることにします。 環境はそれぞれ異なりますが、機能は共通です。このシリーズのブログ記事では、各コンポーネントについて、データベースを移行する際に考慮する概要情報をお伝えするにとどめています。アプリケーションのコンポーネントや各種のシナリオについて、込み入った複雑な点までは取り上げていません。利用状況に応じて大きく変わるからです。細かい点まで深く把握する必要がある場合は、AWS Database ブログの記事 Database Migration—What Do You Need to Know Before You Start? をお読みください。 このシリーズには 3 つのブログ記事があり、それぞれで移行の 3 段階を扱っています。 ステージ 1: 移行プロセスとインフラストラクチャに関する考慮事項。この記事では、ソースサーバーのインフラストラクチャ設定について説明しています。移行プロセスの概要レベルについても触れており、Oracle データベースとクライアントハードウェアおよびオペレーティングシステムに適宜アクセスする必要があります。 ステージ 2: Oracle および AWS DMS […]

Read More

Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行するための成功事例: Oracle および AWS DMS CDC 環境のソースデータベースに関する留意事項

AWS クラウドにおける Oracle から PostgreSQL への移行は、評価段階からカットオーバー段階まで、さまざまな技術とスキルを伴う複雑な多段式のプロセスになる可能性があります。伴う複雑さの内容をさらに詳しく理解するには、AWS データベースのブログ投稿をご参照してください。データベースの移行 – 開始する前に知っておくべきこととは? このブログの投稿は一連の投稿の 2 回目です。前回の移行プロセスとインフラストラクチャに関する留意事項では、移行プロセスの準備について、そして最適なパフォーマンスを手に入れるためのインフラストラクチャ設定の注意点について説明しています。この 2 回目の記事では、元の Oracle データベースの構成と環境を両方とも 1 回の移行と、 change data capture (CDC) という方法による継続的なレプリケーションで設定する方法について説明しています。ソースデータベースの変更を保存するために Oracle DB コンポーネントを適切に設定することにより、思い通りに AWS Database Migration Service (AWS DMS) のサービス環境を構築することができます。このシリーズの3回目となる最後のブログ記事は、AWS DMS を使用したデータベース移行プロセスのエンドポイントである、ターゲットのPostgreSQLデータベース環境の設定を取り上げます。 AWS DMSは、Amazon RDSまたはAmazon EC2のデータベースのオンプレミスデータベースを Amazon RDS またはAmazon Auroraデータベースに移行するためのサービスです。Amazon DMS は、 Oracle から Oracle への同機種間の移行や、 AWS クラウドの Oracle から MySQL 、PostgreSQL […]

Read More

Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行する上でのベスト プラクティス: PostgreSQL 環境のターゲット データベースに関する考慮事項

AWS クラウドで Oracle から PostgreSQL に移行するプロセスは何段階もあって複雑になりがちです。評価ステージから切り替えステージまで、さまざまなテクノロジーとスキルが必要になります。このブログ記事は、データベース移行で考慮すべきコンポーネントに関する高水準の側面について説明するシリーズの第 3 回です。このシリーズでは、アプリケーション コンポーネントや各種のシナリオについて、込み入った複雑な点までは取り上げていません。利用状況に応じて大きく変わるからです。細かい点まで深く把握する必要がある場合は、AWS Database ブログの記事「データベースの移行—始める前に知っておく必要のある事柄」をお読みください。 以前の記事、「移行プロセスとインフラストラクチャに関する考察」および「Oracle および AWS DMS CDC 環境でのソース データベースの考察」では、Oracle データベースの構成方法について説明しました。この考察には AWS Data Migration Service (AWS DMS) および AWS Schema Conversion Tool (AWS SCT) のセットアップが含まれていました。これらの設定後、かつデータ移行の開始前に、ターゲットの PostgreSQL データベースを、関連するすべてのスキーマとパラメータを使って起動および稼動させる必要があります。 このシリーズの最後のブログ記事では、AWS DMS と AWS SCT を使用して Oracle データベースからの移行を支援するために PostgreSQL 環境を設定する方法の概要を示します。この記事では、移行セットアップに役立つ PostgreSQL データベースパラメータの構成について説明します。 移行環境では、高可用性、スケーラビリティ、アーカイブ、バックアップ、負荷分散、およびロールバックのための戦略を採用することもお勧めします。これらの戦略については、この記事では扱いません。また、データベース移行の手動部分については触れません。独自の要件やアプリケーションの依存関係の複雑さに合わせて調整できるステップバイステップの手順も含まれません。これらの詳細については、「PostgreSQL を使用した Oracle Database 11g/12c から Amazon Aurora […]

Read More

AWS Dev Day Tokyo 2018 セキュリティセッション & ワークショップ 開催レポート

  皆様、こんにちは。セキュリティソリューションアーキテクトの桐山です。 2018/10/29(月)から11/2(金)にかけて開催されたAWS Dev Day Tokyo 2018で実施された、セキュリティ関連のセッションとワークショップをおさらいしてみます。 開発者向けカンファレンスということで、この度はセキュリティに興味のある多くの開発者にご参加いただきました。これから企業がデジタルトランスフォーメーション(DX)時代に向かっていく中、開発者の役割も更に高度化・専門化しています。 事業部門で、いわゆるSysmem of Engagement(SoE)領域に携わる開発者は、下記のような今までにない新しいワークロードをセキュアに開発することに挑戦しているでしょう。 IoTサービスにより、様々なデバイスから大量の信頼性の高い実データを収集する 企業内データを一元的に集約・保存する場所(データレイク)をセキュアに管理・運用する 迅速にビジネスインサイトを活用するために、データ分析・可視化・利用をサーバーレスコンピューティング環境で実現する 上のそれぞれに相当するIoTセキュリティ、データレイクセキュリティ、サーバーレスセキュリティは新しいセキュリティ技術領域と言えます。 一方で、IT部門にて、いわゆるSystems of Record(SoR)領域に携わる開発者は、事業成長を支えるセキュリティ基盤を実現しなければなりません。ITインフラ自体を変革させると同時に、事業活動の変化やスピードに対応するためにSecurity as a ServiceやSecurity Automationに取り組むことになるでしょう。 このようなDX時代のセキュリティをAWSで実現するとしたら・・・以下のワークショップとセッションが役に立つはずです。

Read More

RDS データベースに汎用 IOPS またはプロビジョンド IOPS のどちらを使用するかを決定するための CloudWatch メトリクスの使用方法

 このブログ記事では、最高のパフォーマンスのミッションクリティカルなデータベースワークロードに対して、IO1 としても知られるプロビジョンド IOPS からメリットを得ることができる機会を把握するために Amazon CloudWatch メトリクスを使用する方法について説明します。まず、バーストを生じない一貫性のある高書き込みワークロードをシミュレートするテストケースをセットアップすることから始めます。今回は、価格とパフォーマンスのバランスを保つ、GP2 ボリュームとしても知られる汎用ストレージを使ったデータベースと、IO1 ボリュームを使ったデータベースのパフォーマンスを比較します。次に、対応する CloudWatch メトリクスが明らかにする事柄と、ワークロードのパフォーマンス結果をご覧いただきます。 数ヵ月前、GP2 ボリュームでのバーストバランスとベースラインパフォーマンスを説明する Understanding burst vs. baseline performance with Amazon RDS and GP2 という素晴らしいブログ記事が AWS データベースブログに掲載されました。GP2 ボリュームはプロビジョニングが簡単で使いやすく、低価格です。これは、GP2 ボリュームが必要時にパフォーマンスをバーストさせ、散発的なワークロード、または待機時間が発生する可能性を許容できるアプリケーションを上手く処理できることが理由です。開発、機能テスト、およびサンドボックスなどの環境では、偶発的な負担がかかる場合でさえも GP2 の使用には何ら問題がありません。絶えず負担がかかるデータベースワークロードについては、プロビジョンド IOPS ボリュームがプロビジョニングするレベルでの持続的なパフォーマンスとスループットを提供します。 前提条件 始める前に、先ほど紹介した GP2 バーストパフォーマンスについてのブログ記事、Understanding burst vs. baseline performance with Amazon RDS and GP2 を十分に検討してください。 この記事にあるコードを一通り実行したい場合は、アカウント内に同一の Amazon RDS for MySQL データベースを 2 つ作成してください。ひとつのインスタンスには […]

Read More

Amazon Aurora PostgreSQL によるフェイルオーバー

レプリケーション、フェイルオーバー、レジリエンス、災害対策、バックアップ—従来の、または非クラウドベースのアーキテクチャでは、これらの一部またはすべてを実現するのはとても困難です。さらに、時にはかなりのリエンジニアリング作業が必要になることがあります。関係する実装やインフラストラクチャのコストが高いため、一部の企業では最も重要なアプリケーションのみが適切に保護されるようにアプリケーションを階層化せざるを得ません。 こうした懸念は、Amazon Aurora for PostgreSQL に移行すること軽減できます。AWS は、Oracle、MySQL、PostgreSQL、Aurora を含む (ただしこれらに限定されない) 幅広い種類のリレーショナルデータベースエンジンを提供しています。PostgreSQL の場合、AWS は Amazon EC2 インスタンスでの PostgreSQL、Amazon RDS for PostgreSQL、Amazon Aurora with PostgreSQL compatibility を含むさまざなバリエーションをサポートしています。適切なバージョンの PostgreSQL を選択するための多くの指標の中で、以下のいくつかが重要です。 高可用性 (HA) パフォーマンス 管理のしやすさ それでは、Amazon Aurora PostgreSQL がこうした基準をどのように満たしているかを掘り下げてみましょう。 高可用性: HA は、Aurora PostgreSQL のアーキテクチャに組み込まれており、3 つのアベイラビリティーゾーンにわたって 6 つのデータコピーが維持されています。つまり、アベイラビリティーゾーンごとに 2 つのコピーがあることになり、いずれかのアベイラビリティーゾーン全体がダウンしてもわずかな中断で済むことから可用性が向上します。さらに、データベースは Amazon S3 に継続的にバックアップされるため、S3 の高耐久性 (99.999999999) をバックアップで利用できます。Aurora PostgreSQL は、ポイントインタイムリカバリもサポートしています。 パフォーマンス: Amazon Aurora […]

Read More

専用の AWS Glue VPC を使用して複数の VPC 間で ETL ジョブに接続し、実行する

多くの組織では、Amazon VPC サービスに基づく複数の VPC を含む設定を使用し、セキュリティ、監査、コンプライアンス目的で個別の VPC で隔離されたデータベースが使用されます。このブログ記事では AWS Glue を使用して、複数の VPC にあるデータベースで、抽出、変換、ロード (ETL)、クローラー操作を実行する方法を示します。 ここで紹介するソリューションは、専用の AWS Glue VPC とサブネットを使用して、異なる VPC に配置されたデータベースに対して次の操作を実行します。 シナリオ 1: Amazon RDS for MySQL データベースからデータを取り込み、これを AWS Glue で変換し、結果を Amazon Redshift データウェアハウスに出力します。 シナリオ 2: Amazon RDS for MySQL データベースからデータを取り込み、これを AWS Glue で変換し、結果を Amazon RDS for PostgreSQL データベースに出力します。 このブログ記事では、1 つの VPC の 1 つのソースから消費し、別の VPC […]

Read More

ソートキーを使用して、Amazon DynamoDB でデータを編成する

 Amazon DynamoDB テーブルにデータを入力することは難しくありません。さらにデータの整理に頭を悩ませることなく、データ検索オプションを後で制限することができます。 データ検索のためのデータの編成とプランニングは、テーブルを設計する際に大切な手順のうちの一つです。適切なデータ編成がない場合、データを取得するための唯一のオプションは、パーティションキーによる検索かテーブルのフルスキャンしかありません。これらの検索方法では、テーブルは高価となり、パフォーマンスは限られたものになります。 この記事では、ソートキーを使用した、データを取得するための最適化テーブルの実際の例について検討します。ソートキーを使用すると、データをグループ化し編成するだけでなく、テーブル内の項目に対してクエリを実行する追加手段にもなります。 パーティションキーの簡単な紹介 データの編成方法についてよりよく理解するためには、データが DynamoDB に格納される方法を知っておくことが大切です。DynamoDB テーブルの各項目には、DynamoDB のドキュメントに記載されているように、テーブルのプライマリーキーを作成する必要があります。プライマリーキーは、パーティションキー、またはパーティションキーとソートキーの組み合わせです。プライマリーキーは、テーブル全体で固有のものでなければなりません。 パーティションキーのみをプライマリキーとして使用する場合、最適とはいえないパーティションキーを選択し、その結果、テーブルの全体的なパフォーマンスに影響する可能性があります。例えば、同じプライマリキーを頻繁に取得すると、スループットが超過した例外が発生し、テーブルへのリクエストを抑制する可能性があります。 パーティションキーとそのベストプラクティスの詳細については、AWS データベースブログの「正しい DynamoDB パーティションキーの選択」の記事を参照してください。 ソートキーを使用して、データ検索オプションを拡張する 場合によっては、テーブルを作成する時に、プライマリキーとしてパーティションキーのみを提供する場合があります。このような場合、パーティションキーによるデータの取得、またはスキャン操作でテーブル内のすべての項目の返送に限定されます。このようにテーブルを作成するのは簡単で、場合によってはとてもシンプルです。 ただし、データセットが増加するにつれて、テーブルスキャンは価格とパフォーマンスの面で大きな負担となります。テーブルスキャンは、読み取り容量をすぐに使い果たしてしまうため、請求額が増加します。読み書きの容量単位、およびこれらの単位が DynamoDB 請求書に与える影響の詳細については、DynamoDB ドキュメントの「Amazon DynamoDB 料金表」と「読み書きの処理能力」を参照してください。さらに、パーティションキーだけで、項目の取得ができるとは限りません。特定の日付の前に顧客の注文を検索し、カテゴリーに一致するすべての商品を取得する例を考えてみましょう。ソートキーをテーブルに追加すると、スキャンやパーティションキーを利用する以上に、より多くのデータ検索機能が利用可能となります。 ソートキーは、クエリによって返される項目のソート順を決定するためだけのものではないことに留意しましょう。この記事が示すように、ソートキーは検索のために項目を直接ソートするのではなく、データ検索オプションを拡張します。 パーティションキーとソートキーを組み合わせると、コンポジットキーが作成され、それらのコンポジットキーはテーブル内の個々の項目のプライマリキーになります。コンポジットキーを使用すると、ソートキーに対して KeyConditionExpression でクエリを使用することが可能となります。クエリでは、KeyConditionExpression を用いて、キーに対して評価して返される項目を制限する比較演算子を利用し、条件文を記述できます。つまり、特殊演算子を使用して、項目をソートキー値でインクルード、除外、および照合することができるわけです。 ソートキーを使ってクエリを実行する例と、時間によってクエリを実行する例を、簡単に見てみましょう。特定のテーブルのソートキーが、数値として格納された Unix タイムスタンプであるとします。この場合、特定の時刻の前に < 比較演算子を使用して、すべての項目を返すというキー条件でクエリを発行できます。時間を限定した検索の例を、後ほど考察しましょう。 範囲を使う ソートキーに関連した範囲を使用して、クエリを作成します。KeyConditionExpressions クエリでは、次の演算子を使用できます。 = < > <= >= between begins_with between 演算子は範囲を決定するために 2 つの値を受け取り、begins_with 演算子は文字列が部分文字列で始まるかどうかを調べます。これらの演算子のほとんどは数値を使用できますが、beginning_with 演算子では面白い方法でデータをクエリできます。 例えば、場所をグループ化する方法を検討するとしましょう。米国では、場所は通常、都市、州、郡でグループ分けします。city-state-country のテンプレートを使用して、項目の場所を文字列に格納するソートキーを作成したとします。 city-state-country の順序は、場所データの最も具体的な部分から開始します。結果として、beginning_with […]

Read More

AWS Lambda、Amazon Route 53、および Amazon SNS を使用して、Redis クラスター用 Amazon ElastiCache (クラスターモードが無効) のリードレプリカエンドポイントを監視します

 Redis 用 Amazon ElastiCache では、アプリケーションが指定されたエンドポイントを使用して ElastiCache ノードまたはクラスタに接続します。Redis 用 ElastiCache ユーザーガイドのRedis 用 ElastiCache コンポーネントと機能によると、複数のノードを持つ Redis (クラスターモード無効) クラスターには次の 2 種類のエンドポイントがあります。 「プライマリエンドポイントは、プライマリロール内の特定のノードが変更された場合でも、常にクラスタ内のプライマリノードに接続します。クラスターへのすべての書き込みにプライマリエンドポイントを使用します。Redis (クラスターモードが無効) クラスターの読み取りエンドポイントは、常に特定のノードを示します。リードレプリカを追加または削除するときは、アプリケーションで関連するノードエンドポイントを更新する必要があります。」 Redis 用 ElastiCache のプライマリエンドポイント機能は、プライマリノードエンドポイントを解決する際に常に一貫性を提供します。AWS の顧客はこの機能を高く評価しています。 「ElastiCache Redis の便利な機能は、クラスターの現在のプライマリノードを常に示す、プライマリエンドポイントを利用できる点です。このエンドポイントは、クラスターにフェイルオーバーが発生しても変更されません。したがって、プライマリノードが変更されてもアプリケーションを変更する必要はありません。この機能は、自動フェイルオーバーが発生した場合に特に役立ちます。」—AWS の顧客 ベストプラクティスとして、およびワークロードバランシングのため、リードレプリカに読み取りリクエストを送信する必要があります。ただし、フェイルオーバーが発生した場合は、以前に使用したリードレプリカをプライマリロールに昇格させることができます。読み取りリクエストを同じエンドポイントに送信し続けると、新しいプライマリ (古いリードレプリカ) の負荷が増える可能性があります。この場合、フェイルオーバー発生後であっても、常にレプリカを示すリードレプリカエンドポイントがあると便利です。 これを行うには、リードレプリカエンドポイントの監視および更新が可能な AWS Lambda 関数を設定します。この目的は、Amazon Route 53 のプライベートゾーンにある各リードレプリカに対してカスタムの CNAME を作成して使用し、これらの CNAME を Redis のクライアントで使用することです。 フェイルオーバーが発生すると、Amazon Simple Notification Service (Amazon SNS) トピックにプッシュ通知が配信されます。この SNS […]

Read More

New Innovations はいかにして研修医管理プラットフォームを Microsoft SQL Server から Amazon Aurora PostgreSQL へ移行したのか

 この記事は New Innovations の IT マネージャー、Stephen Sciarini 氏によるゲスト投稿です。 New Innovations が構築してきたビジネスは、すべてがさらに大きな目的 (質の高い医学教育を提供する権限を医療教育者や管理者に与えること) を示唆する共有されたアイデアや信念に基づいています。インテリジェンスは、タスクとテクノロジーを区別しないところまで進歩しており、その結果、医療研修生や教育者は日常の管理義務から解放されます。医療教育分野のパートナーは当社と協力して、この理想的な未来の実現に取り組んでいます。 その未来はそれほど遠くはありません。AWS と Amazon Aurora PostgreSQL のおかげで、当社は顧客の要求を満たすために拡大したインフラストラクチャを構築することができました。AWS Database Migration Service(AWS DMS) によって、Aurora PostgreSQL への移行は、リスクを最小限に抑えながら、顧客と当社のソフトウェア開発者の両方にとってシームレスな体験となりました。AWS DMS を使用し、Microsoft SQL Server の 700 以上のインスタンスを Aurora PostgreSQL に完全に移行しました。さらに、Amazon RDS Performance Insights によってデータベースレイヤーの優れた可視性が得られるため、あらゆる異常に素早く対応することができます。 会社沿革 1995 年以来、New Innovations は医療研修医データを収集し管理する方法を再考し続けています。私たちは、適格認定を取得し維持するための機能を含む、卒後医学教育 (GME) および学部医療教育 (UME) プログラムが単一システムで必要とするすべてのものを提供します。当社のソフトウェアスイートが管理と実行可能なタスクを簡素化し、教職員とスタッフの手間を省き教育に専念できるよう働きます。学生、居住者、特別研究員の受け入れから、スケジューリングとパフォーマンス分析まで、New Innovations が意のままに管理します。 今日、当社のソフトウェアは世界中に広がっており、病院、メディカルスクール、個人開業医において数多くの医療教育分野に貢献しています。私たちの夢は、医療教育が直面する管理上の拘束から解放された世界です。そうなれば医療機関は、いつか私たちの世代がお世話になる介護者の育成に集中することができます。 当初は… 2014 […]

Read More