Amazon Web Services ブログ

Category: Database

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

Oracle 自律型トランザクションを PostgreSQL に移行する

データベースを移行し稼働させるには、複雑な手順と細部にわたる計画が必要になります。Amazon RDS for PostgreSQL および Amazon Aurora は PostgreSQL と互換性があり、さまざまなユースケースの取扱いに役立ちます。Oracle から PostgreSQL への移行では、Oracle 自律型トランザクションというものがよく話題になります。このブログ記事では自律型トランザクションと、この機能を PostgreSQL で実現する方法について説明します。 永続データのユースケース データベースのトランザクションでは、すべてのステートメントがコミットまたはロールバックされるように SQL ステートメントをグループにしてまとめるメカニズムを提供します。たとえば、口座 A から口座 B へ資金を移動する場合は、以下のような手順を踏む必要があります。 口座 A から必要な金額を引く 口座 B に必要な金額を足す このシナリオでは、両方の手順が成功しているか、両方が失敗しているかのいずれかを確認する必要があります。これは、データベースのトランザクションで両方の SQL ステートメントを実行することで可能になります。これは非常に役に立つ機能です。また多くのユースケースで必要になります。ただし、アプリケーションによっては、トランザクションが失敗してもデータを保持する機能が必要なケースもあります。 PostgreSQL と Oracle はいずれも同じトランザクション原理に従っていますが、このユースケースに対応するために、Oracle では自律型トランザクションという機能を提供します。PostgreSQL には自律型トランザクションそのままの機能はありませんが、dblink を使用することで同様の結果を得られます。 自律型トランザクションとは何でしょうか。 Oracle は自律型トランザクション機能を提供しています。この機能では、メイントランザクションのコミットやロールバックを実行することなく、サブプログラムによる SQL オペレーションの実行、さらには各 SQL オペレーションのコミットまたはロールバックが可能です。 以下のようなシナリオを想定してください。 INSERT トリガーのビジネスロジックに従い、重要な情報を持つ 1 行をテーブルに追加する必要があるとします。 SQL の INSERT […]

Read More

SQL Server エージェントのジョブを AWS Step Functions に置き換える

Microsoft SQL Server から Amazon Aurora PostgreSQL への移行の場合に、SQL エージェントのジョブを簡単に移動できないことにお気づきかもしれません。Aurora PostgreSQL ではジョブエージェントツールがサポートされていません。この制限を克服するには、AWS Step Functions を使用して SQL エージェントのジョブを置き換えます。 このブログ記事では、ステップ関数を作成して、SQL ストアドプロシージャを実行する SQL エージェントのジョブを置き換える方法を示します。 ソリューションを実行するためのステップ このソリューションを実行するためのコードと AWS CloudFormation テンプレートは、この GitHub Amazon Repository にあります。 ソリューションを作成するために、CloudFormation テンプレートを使用して以下を準備します。 パブリックで利用可能なスナップショットからの SQL Server データベース用の Amazon RDS。 ステートマシン用の IAM ロール。 Step Functions アクティビティ。 Step Functions ステートマシン。 Step Functions ステートマシンを起動するための Amazon CloudWatch Events ルール。 CloudFormation テンプレートを使用して上記のリソースを準備した後に、以下の操作を実行します。 […]

Read More

Amazon RDS for SQL Server 上で SQL Server 2008 R2 から SQL Server 2016 にアップグレードする方法に関するベストプラクティス

 このブログ記事では、Microsoft SQL Server 2008 R2 のサポート終了に備えて、Amazon RDS for SQL Server 上で SQL Server 2008 R2 から SQL Server 2016 にアップグレードする方法を中心にご紹介します。また、ご紹介するプラクティスの多くは、SQL Server のすべてのバージョン、あるいは他の RDS のエンジンにも適用することができます。 注意: 現在、SQL Server 2008 R2 から RDS の SQL Server 2017 へのアップグレードパスはありません。SQL Server 2017 にアップグレードする場合は、2012、2014、または 2016 にアップグレードしておく必要があります。 自己管理型プラットフォームでは、最新のデータベースバージョンへのアップグレードに多くのリスクが伴います。多くの企業は「壊れてないものは直すな」をモットーとしています。 幸い、自己管理型プラットフォームでふだん直面する課題の多くは、Amazon RDS が提供する自動化によって軽減されます。 SQL Server DB インスタンスの場合、アップグレードには次の 2 種類があります。 メジャーバージョンのアップグレード (SQL Server […]

Read More