Amazon Web Services ブログ

 今回は、AWS Schema Conversion Tool (AWS SCT) 新バージョンをご紹介します。このバージョンには、テーブル値関数の変換のサポート、サーバーレベルの評価レポートへの追加情報などが含まれます。 AWS SCT とは、あるデータベースエンジン上の既存のデータベーススキーマを別のデータベースエンジン用に変換するためのツールです。リレーショナル OLTP スキーマやサポート対象のデータウェアハウス OLAP スキーマを Amazon RDS に変換することができます。たとえば、MySQL や PostgreSQL などと互換性があるため、Amazon Aurora に変換できます。また、リレーショナル OLTP スキーマやサポート対象のデータウェアハウス OLAP スキーマを Amazon Redshift に変換することも可能です。サポートされているすべてのソースおよびターゲットは、AWS SCT ドキュメントで確認できます。 以下に、この記事で説明するトピックの概要を示します。 Microsoft SQL Server から PostgreSQL へ – テーブル値関数の変換 SQL Server から PostgreSQL/MySQL へ – テーブル型変数の変換 SQL Server から PostgreSQL へ – MERGE ステートメントの実装 Oracle から […]

 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 […]

 この記事は 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 […]

データベースを移行し稼働させるには、複雑な手順と細部にわたる計画が必要になります。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 […]

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 テンプレートを使用して上記のリソースを準備した後に、以下の操作を実行します。 […]

 Elasticsearch は、インデックス作成を含めたあらゆる目的に対応する REST API オペレーションを備えています。REST API に加えて、最も一般的な開発言語用に AWS SDK もあります。このガイドでは、REST API を使用して、言語にとらわれない方法で基礎となるテクノロジーについて学ぶことができます。 インデックス作成が Elasticsearch のコアです。数テラバイトのデータを超高速で検索することができます。しかし、存在していないデータを検索することはできません。そこでこの記事では、インデックスを作成し、データを Elasticsearch に入れ、Amazon Elasticsearch Service を使用して Elasticserach で検索する方法を説明します。 Amazon Elasticsearch Service ドメインの作成 まだ AWS アカウントを持っていなければ、AWS アカウントにサインアップしましょう。新規アカウントでサインアップした際、無料利用枠を使用すると Amazon Elasticsearch Service を 12 ヶ月間無料で利用できます。また Amazon Elasticsearch Service を始めるのはとても簡単です。 アカウントが準備できたら、Amazon Elasticsearch Service ドメイン (クラスターの設定あり) を作成します。1 つを取得するには (約 15 分かかります)、Amazon Elasticsearch Service ドメインの作成と設定の手順に従ってください。 Amazon […]

 このブログ記事では、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 […]

企業は長年、独自にローカルデータベースを設定し、ハードウェアを自社で管理する必要がありました。しかし、クラウドインフラストラクチャが向上し続けており、自社でハードウェアを所有・管理する必要が格段に少なくなっています。 Amazon では、所有している何百 (あるいは何千もの) オンプレミスのデータベースを、時間をかけてクラウドベースのソリューションに移行しました。このソリューションには、Amazon RDS のようなリレーショナルなものと、Amazon DynamoDB のような非リレーショナルなものの両方があります。リレーショナルなソリューションに移行したデータベースでは、無料で使用でき、Oracle データベースと類似の機能 (シーケンス、トリガー、パーティション) を持つデータベース技術を検討してコストを削減しようとも試みました。技術面でそれに最も近いものが、PostgreSQL です。 このブログ記事には 2 つのセクションがあります。まず、共通の Java アプリケーションと Hibernate のレイヤー (オブジェクトリレーショナルマッピング) における変更について述べます。その後、Java アプリケーションを Oracle から Amazon RDS for PostgreSQL に移行した際に明らかとなった、アプリケーション層を管理するためのベストプラクティスと方針について述べます。今回の提案と事例は、RDS および PostgreSQL と互換性のある Amazon Aurora の両方を基盤としたデータベースを対象とするものです。 Hibernate とアプリケーションレイヤーの変更およびベストプラクティス まず、お使いのアプリケーションを分析することから始めます。移行を成功させるために、移行予定のアプリケーションについて深く理解することをおすすめします。以下は開始するにあたり、全体についての質問です。 お使いのアプリケーションは、Hibernate のようなオブジェクトリレーショナルマッピング (ORM) を使用していますか? 使用している場合、アプリケーションでどの Hibernate データ型を使用していますか? お使いのアプリケーションには変換を必要とする可能性のあるプレーン SQL が今もありますか? この中からいくつかの質問を取り上げ、なぜそれが重要なのかを考えてみましょう。 お使いのアプリケーションは ORM を使用していますか? アプリケーションが ORM […]

AWS の顧客は、Amazon DynamoDB を使用してミッションクリティカルなデータを保存しています。このような顧客のアプリケーションから 1 秒に何百万ものリクエストが、何百テラバイトの項目を含む個々の DynamoDB テーブルに送られます。顧客は DynamoDB が瞬時に結果を返すことを頼りにしています。 多くの場合、これらのアプリケーションには特定のトランザクション、監査、またはアーカイブトランザクションについて他のシステムとユーザーに通知し、データを別のデータストアにほぼリアルタイムでレプリケートするという要件があります。これらの要件は、DynamoDB 内の項目への変更の順序を維持することで満たすことができます。このような機能を構築するには、DynamoDB 内の項目への変更が並列処理され、ほぼリアルタイムのパフォーマンスを達成することが必要です。 Amazon DynamoDB ストリーム を他の AWS サービスと統合して、順序付けられたほぼリアルタイムのデータ処理機能を構築することができます。DynamoDB ストリームは、DynamoDB テーブルの項目レベルの変更に対して時間順序のシーケンスをキャプチャし、その情報を最高 24 時間まで保存します。そしてアプリケーションからは、ほぼリアルタイムで DynamoDB ストリームからの一連のストリームレコードにアクセスすることができます。 この記事では、AWS サーバーレスコンピューティングの一部である複数の AWS サービスを使用して DynamoDB ストリームを処理するための複数のパターンを評価します。また、他のシステムやユーザーに通知し、トランザクションをアーカイブし、順序付けされた処理を維持しながらデータを別のデータストアにレプリケートするために、ほぼリアルタイムの DynamoDB ストリーム処理を実行できる最も信頼性の高いスケーラブルなパターンの詳細にも触れます。 AWS Lambda を使用した DynamoDB ストリームの処理 AWS Lambda は、サーバーをプロビジョニングまたは管理せずにコードを実行できるサービスです。たとえば Lambda は、DynamoDB ストリームのイベント (項目の挿入、更新、削除など) に基づいてコードを実行できます。Lambda は DynamoDB ストリームをポーリングし、新しいレコードを検出すると Lambda 関数を呼び出し、1 つ以上のイベントを実行します。 Lambda による DynamoDB […]

ネットワークログの分析は多くの組織で一般的に実施されています。  ネットワークログを収集し、分析することにより、ネットワーク上のデバイスがそれぞれ、およびインターネットとどのように通信しているかを把握できます。  たとえば、監査、コンプライアンス、システムのトラブルシューティング、セキュリティフォレンジックなど、ログ分析を実行する理由は多数あります。  Amazon Virtual Private Cloud (VPC) では、VPC Flow Logs を使用してネットワークフローをキャプチャできます。  VPC、サブネット、ネットワークインターフェイス用のフローログを作成できます。  サブネットまたは VPC のフローログを作成した場合、VPC の各ネットワークインターフェイスまたはサブネットがモニタリングされます。フローログのデータは Amazon CloudWatch Logs のロググループに公開され、各ネットワークインターフェイスにはユニークなログストリームが作成されます。 CloudWatch Logs にはこのログデータの洞察を確保するうえで有用なツールがいくつか用意されています。  しかし、ほとんどの場合、ログデータを S3 に効率的にアーカイブし、SQL を使用してクエリ検索する手法が好まれます。  この手法ではログの保存に対しより大きな柔軟性と管理性が得られるとともに、必要な分析も実行できるようになります。  しかし同時に、分析を自動的に実行することでログデータが生成された直後にログデータの洞察をほぼリアルタイムで取得する機能もよく好まれる傾向にあります。  また、VPC 内のネットワークトラフィックをより明確に理解できるよう、ダッシュボードである程度のネットワークの特徴を視覚化することにも関心が集まっています。  つまり、S3 への効率的なログのアーカイブとリアルタイムのネットワーク分析、データの可視化のすべてを達成するにはどうすればよいでしょうか?  これは、CloudWatch、Amazon Kinesis、AWS Glue、Amazon Athena などの複数の機能を組み合わせることで達成自体は可能ですが、このソリューションをセットアップし、すべてのサービスを構成するのは容易ではありません。 このブログ記事では、VPC フローのログデータを収集、分析、資格するための完璧なソリューションについて解説します。  さらに、独自のアカウントにこのソリューションを効果的にデプロイできる 1 つの AWS CloudFormation テンプレートを作成しました。 ソリューションの概要 このセクションではアーキテクチャの概要とこのソリューションの各ステップについて解説します。 私たちは 1 回限り、またはアドホックでフローログデータをクエリする機能を必要としています。また、ほぼリアルタイムでそれを分析できる手立ても必要です。つまり、私たちのフローログデータはこのソリューションを通して 2 つのパスを取ることになります。  アドホッククエリには、Amazon […]