Amazon Web Services ブログ

AWS CodeCommitのプルリクエストを使用してコードレビューをリクエストし、コードについて議論する

シニアクラウドアーキテクトのMichael Edge氏のCodeCommitのプルリクエストに関する素晴らしいブログに感謝します。

~~~~~~~~~~~~~
AWS CodeCommitは、プライベートGitリポジトリを安全にホスティングするフルマネージドなサービスです。CodeCommitは今ではプルリクエストをサポートするようになりました。これによってリポジトリのユーザは、コードの変更に対するレビュー、コメント、対話的なイテレーションが可能になります。チームメンバー間のコラボレーションツールとして使用されるプルリクエストは、CodeCommitリポジトリに対する変更の可能性を、リポジトリにそれらの変更をマージする前に確認するのに役立ちます。各プルリクエストは、次のように単純なライフサイクルを通じて実行されます:

  • マージされる新機能は、featureブランチに1つ以上のコミットとして追加されます。コミットは、宛先のブランチにマージされません。
  • プルリクエストが通常は2つのブランチの差異から作成されます。
  • チームメンバーはプルリクエストをレビューし、コメントします。プルリクエストは、追加のコミットで更新される可能性があります。これにはコメントに対応して行われる変更や宛先ブランチとの差分から発生する変更が含まれます。
  • チームメンバーがプルリクエストに満足すれば、それは宛先ブランチにマージされます。 コミットは、プルリクエストに追加されるのと同じ順序で宛先ブランチに適用されます。

(more…)

AWS Shield Advancedを使用してAmazon EC2インスタンスとNetwork Load Balancerを保護できるようになりました

11月22日から、AWS Shield Advancedは、インフラストラクチャレイヤの分散サービス拒否(DDoS)攻撃からAmazon EC2インスタンスとNetwork Load Balancerを保護できるようになりました。 AWS Elastic IPアドレスに対してAWS Shield Advancedを有効にし、インターネットに接続されたEC2インスタンスまたはNetwork Load Balancerにアタッチすることで利用可能です。 AWS Shield Advancedは、Elastic IPアドレスの背後にあるAWSリソースの種類を自動的に検出し、DDoS攻撃を緩和します。

AWS Shield Advancedは、Amazon VPCネットワークアクセスコントロールリスト(ACLs)をAWSネットワークのエッジにあるAWS Shield上で自動的に実行し、追加の帯域幅とスクラビング容量を利用することで、大量のDDoS攻撃を軽減します。また、AWS DDoS対応チームと協力し、事前に軽減策を設定したり、発生したインシデントに対応したりすることで、AWS Shieldの追加の軽減策をカスタマイズできます。AWS Shield Advancedによって検出されたすべてのインシデントについては、Amazon CloudWatchのメトリックを通じて、ほぼリアルタイムに可視化されます。インシデントの詳細についても、攻撃の地理的な起点や送信元IPアドレスなどが確認いただけます。

Elastic IPアドレスに対応したAWS Shield Advancedは、DDoSコスト保護の適用範囲を拡大します。DDoSコスト保護により、DDoS攻撃の結果として利用リソースが増加した場合に、Elastic Load BalancingAmazon CloudFrontAmazon Route 53、およびEC2インスタンス時間についてサービスクレジットを要求できるようになりました。

EC2インスタンスとNetwork Load Balancer保護の開始

開始方法:

  1. AWS Management Consoleにサインインし、AWS WAFおよびAWS Shieldコンソールに移動します。
  2. 「AWS Shield Advancedを有効にする」を選択、条件をご確認いただき、AWS Shield Advancedを有効化します。
  3. ナビゲーションペインで「Protected resources」に移動します。
  4. 保護するElastic IPアドレスを選択します(これらはEC2インスタンスまたはネットワークロードバランサを指し示します)。

AWS Shield AdvancedがDDoS攻撃を検出した場合、CloudWatchを確認するか、AWS WAFおよびAWS Shieldコンソールの「Incidents」タブを調べることで攻撃の詳細を取得できます。 この新機能とAWS Shield Advancedの詳細については、AWS Shieldのホームページを参照してください。

この投稿に関するご意見やご質問は、(原文)記事の「コメント」セクションにお寄せいただく、またはAWS Shieldフォーラムで新しいスレッドを開始いただくか、AWSサポートにお問い合わせください

– Ritwik

原文:Now You Can Use AWS Shield Advanced to Help Protect Your Amazon EC2 Instances and Network Load Balancers(翻訳:SA安司)

 

Amazon Elasticsearch Service へのアクセスコントロールの設定

Dr. Jon Handler (@_searchgeek) は、検索技術を専門とする AWS ソリューションアーキテクトです。

Amazon Elasticsearch Service (Amazon ES) ドメインを保護することで、権限のないユーザーがデータにアクセスしたり変更したりすることを防ぐことができます。ほとんどのお客様は、IP アドレスベースまたは ID ベースのアクセスポリシーのセキュリティを望んでいますが、利便性からオープンアクセスを選択しています。オープンアクセスのドメインは、インターネット上の任意の当事者から Amazon ES ドメインへのデータの作成、表示、変更、および削除の要求を受け入れるため、このオプションはほとんどのお客様にとって適切なものではありません。

以前のブログ記事「Amazon Elasticsearch Service ドメインのアクセスをコントロールする方法」では、アクセスコントロールについて詳細に説明しました。このブログ記事では、ドメインの IAM ポリシーを開始する簡単な方法をいくつか紹介します。AWS Identity and Access Management (IAM) ポリシーを設定するにはいくつかの作業が必要ですが、この「予防的対策」により後で大量の作業が発生するのを防ぐことができます。

Amazon Elasticsearch Service における主要なアクセスコントロールの概念

Amazon ES が作成するドメインには、Elasticsearch クラスタ内のノードと複数の AWS サービスのリソースが含まれます。Amazon ESがドメインを作成すると、ドメインはサービス制御された VPC でインスタンスを起動します。これらのインスタンスの前面には Elastic Load Balancing (ELB) があり、ロードバランサーのエンドポイントはRoute 53 を通じて発行されます。ドメインへのリクエストは、ドメインの EC2 インスタンスにルーティングする ELB ロードバランサをパススルーします。リクエストがどこに行くかに関わらず、インスタンスは IAM にコンタクトしてリクエストが承認されているかどうかを判断します。承認されていないリクエストはブロックされ、破棄されます。

IAM ポリシーがどのように適用され、解決されるかを理解するための鍵は、次の点にあります。

  • ポリシーの場所: IAM ポリシーは、ドメインまたは個々のユーザーまたはロールに付加できます。ポリシーがドメインに付加されている場合は、リソースベースのポリシーと呼ばれます。ユーザーまたはロールに関連付けられている場合は、ユーザーベースのポリシーと呼ばれます。
  • ポリシーの解決: IAM は、リクエストが承認されているかどうかを判断するために、リクエストに適用されるすべてのユーザーベースおよびリソースベースのポリシーを収集します。詳細については、ブログ記事「Amazon Elasticsearch Service ドメインのアクセスコントロールを設定する方法」を参照してください。

リソースベースのポリシー、ユーザーベースのポリシー、またはそれらの組み合わせを作成するかどうかにかかわらず、IAM は特定のリクエストに対してすべてのポリシーを尊重します。

Amazon ES コンソールのウィザードを使用してドメインを作成すると、Amazon Elasticsearch Service はさまざまな種類のアクセスに対していくつかのテンプレート IAM ポリシーを提供します。

  • [1 つ以上の  AWS アカウントまたは IAM ユーザーにアクセスを許可、または拒否する] を選択した場合: ドメインにアクセスする必要がある IAM ユーザーまたはロールを指定します。ドメインへのすべてのリクエストは、AWS 署名バージョン 4 署名で署名する必要があります。リクエストがドメインに到達すると、署名検証とアクセスコントロールのためにリクエストが IAM に転送されます。
  • [Allow access to the domain from specific IP(s) (特定の IP からのアドメインへのアクセスを許可する)] を選択した場合: IP または CIDR ブロックを指定します。その IP アドレス範囲からの匿名 (署名なし) リクエストは許可されます。
  • [Deny access to the domain (ドメインへのアクセスを拒否する)] を選択した場合: 署名付きまたは署名なしにかかわらず、リクエストは許可されません。
  • [Deny access to the domain (ドメインへのアクセスを拒否する)] を選択した場合: 署名付きまたは署名なしにかかわらず、リクエストは許可されません。このテンプレートを選択すると、Amazon ES からポップアップ警告が表示されます。

シンプルな IP アドレスベースのセットアップ
Amazon Elasticsearch Service を使い始めたばかりのときは、データをすばやく読み込んだり、いくつかのクエリを実行したり (コマンドラインから、または Kibana を使用して)、コマンドラインからより詳細な検査と監視を行いたいものです。オープンアクセスポリシーは、ネイティブの Elasticsearch クライアント、curl、ウェブブラウザなどのツールがクラスタとやりとりすることを可能にするため、最も早く始める方法となります。

その性質上、オープンアクセスは安全ではありません。オープンアクセスポリシーはお勧めできません。IP アドレスベースのアクセスコントロールを使用すると、ドメインを保護することができます。不正な訪問者やポートスキャナは、次のようなメッセージで拒否されます。

{“Message”: “User: anonymous is not authorized to perform: es:ESHttpGet on resource:<domain ARN>”}

開発を EC2 インスタンスから行う場合は、VPC を設定してパブリック IP アドレスまたは Elastic IP アドレス (EIP) を割り当てることができます。

この簡単なセットアップで、[Allow access to the domain from specific IPs] オプションを選択すると、次のようなポリシーを生成できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "111.222.333.444/0"
          ]
        }
      },
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    }

 

IPアドレス、アカウント ID、ドメイン名(赤で表示) を必ず自分の値に置き換えてください。

この設定は、開発およびテストのために必要な基本アクティビティをサポートします。curl のようなツールを使ってコマンドをクラスタに直接送ることができます。その EC2 インスタンスで Kibana を実行できます。IP アドレスベースのアクセスポリシーはフルアクセスを許可します。署名されていても匿名であっても、異なる IP アドレスからのドメインへのその他のすべてのリクエストは、IAM によって拒否されます。

Kinesis Firehose、Amazon CloudWatch ログ、または AWS IoT で使用するためのセットアップ
Amazon Elasticsearch Service を開始するには、別の AWS サービスからデータを送信するのが簡単です。Kinesis Firehose ストリームを作成するか、CloudWatch ログデータを Amazon ES にストリーミングするには、これらのサービスがドメインに書き込むことを許可するロールを作成する必要があります。IAM のポリシー解決により、他のサービスからのアクセスが許可され、ドメインにデータを書き込むことができるようになります。IP アドレスベースのポリシーによって、コマンドと Kibana のための EC2 インスタンスへのアクセスが許可されます。他のすべてのリクエストへのアクセスは拒否されます。

AWS IoT の安全なアクセスを設定する方法については、IP アドレスベースのポリシーを使用する方法について説明しているブログ記事「Analyze Device-Generated Data with AWS IoT and Amazon Elasticsearch Service (AWS IoT および Amazon Elasticsearch Service によるデバイス生成データの分析)」を参照してください。

IP アドレスがわからない場合のセットアップ
多くの場合、リクエスト元の静的 IP アドレスはわかりません。データセンター内のノードのセット、モバイルアプリケーションのサポート、または自動スケーリングされた一連のウェブサーバーまたは Logstash インスタンスからのリクエストの送信で、Kibana を実行することができます。

このような場合、VPC の既知の IPアドレスでリバースプロキシを使用して、Kibana から Amazon Elasticsearch Service サービスドメインにリクエストを転送し、ユーザーベースの認証で署名バージョン 4 の署名を使用してアプリケーションサーバーからリクエストを送信できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/webserver "
      },
      "Action": ["es:ESHttpGet"],
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "111.222.333.444/0",   <-- プロキシの IP アドレス
            "112.223.334.445/0"    <-- インスタンスの IP アドレス
          ]
        }
      },
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    }

  ]
}

 

プロキシサーバーの IP アドレスを IP アドレスベースのポリシーに置き換えて、プロキシからのロクエストを許可します。ポリシーに別の IP アドレスを追加して、コマンドラインと Kibana のためのアクセスを開くこともできます。

前述のポリシー例では、ウェブサーバーのロールに許可されているアクションを HTTP GET 呼び出しに制限しています。作成する IAM ポリシーでは、さまざまなコマンドと HTTP メソッドを許可しているため、さまざまなアクターのアクセスコントロールを設定できます。詳細については、ブログ記事「Amazon Elasticsearch Service ドメインのアクセスをコントロールする方法」を参照してください。

プロキシを使用してリクエストの署名を簡素化する
プロキシを作成すると、プロキシの IP アドレスをアイデンティティのソースとして使用して、ドメインへのアクセスをコントロールできます。プロキシから許可されたリクエストのみを発信することによって、アクセスをコントロールします。署名バージョン 4 のリクエスト署名を使用して、リクエストの背後にあるアイデンティティ情報を提供することもできます。Amazon ES は IAM を使用してこれらのリクエストを認証し、許可または拒否します。

リクエストの署名を実装するには、コードを記述する必要があります。これは、コマンドラインまたは Kibana のアクセスのための開発の追加ハードルになります。リクエストを受け取り、署名バージョン 4で署名し、AWS に転送する小さなアプリケーションを提供するオープンソースプロジェクトがあります。

そのような署名プロキシがここにあります: https://github.com/abutaha/aws-es-proxy。この小さなアプリケーションはポート 9200 でリッスンし、署名されたリクエストを Amazon Elasticsearch Service に転送します。

注意: この署名プロキシは、AWS ではなくサードパーティによって開発されたものです。これは開発やテストには適していますが、本番稼働用ワークロードには適していません。AWS は外部コンテンツの機能または適合性について責任を負いません。この署名プロキシを使用すると、1 つ以上の AWS アカウントまたは IAM ユーザーにアクセスを許可、または拒否する テンプレートを使用して、ドメインのポリシーを次のように設定できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/susan"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    }
  ]
}

 

ユーザー ARN と赤のドメイン ARN を生成されたポリシーからのものに置き換えます。プロキシを実行し、127.0.0.1:9200 でリッスンします。次に、curl を使用して Elasticsearch API 呼び出しを http://127.0.0.1:9200/ に送信すると、それらが使用するドメインに転送されます。開発マシン上で Kibana をローカルで実行する場合は、kibana.yml のhttp://127.0.0.1:9200/ を参照してください。

CloudTrail を使用してアクセスポリシーの変更を監視する
Amazon CloudTrail は、さまざまなサービスと対話するときに AWS に送信されるリクエストのログを提供します。Amazon Elasticsearch Service は、ドメインの作成、ドメイン設定の更新、タグの追加など、すべての管理アクションに対して CloudTrail イベントを送信します。CreateElasticsearchDomain および UpdateElasticsearchDomainConfig API 呼び出しの CloudTrail イベントを監視して、組織内のユーザーがドメインを作成または変更するときにアクセスポリシーを検証することをお勧めします。これらのログを使用して、すべてのアクセスポリシーを確認し、前述のプラクティスに準拠していることを確認できます。

まとめ
これで、テストと開発の際にニーズに合ったアクセスポリシーを簡単に設定できることを示すことができたと考えています。ご質問、コメント、ご提案があれば、コメントに投稿してください。

Apache MXNet で ONNX をサポート

AWS は ONNX-MXNet の利用開始を発表しました。これは Open Neural Network Exchange (ONNX) ディープラーニングモデルを Apache MXNet にインポートするためのオープンソース Python パッケージです。MXNet は充実した機能を備えたスケーラブルなディープラーニングフレームワークで、Python、Scala、R といった人気の言語に対し API を提供します。MXNet で ONNX 形式をサポートすることで、開発者は PyTorch、Microsoft Cognitive Toolkit、Caffe2 など、他のフレームワークを使用してモデルを構築したりトレーニングすることができます。また、高度に最適化されたスケーラブルなエンジンの MXNet を使用した推論に対し、こうしたモデルを MXNet にインポートすることもできます。

AWS が ONNX 形式に貢献できることを大変喜ばしく思っています。FacebookMicrosoft、そしてディープラーニングコミュニティと協力し、ディープラーニングのユーザーが利用しやすい便利なものにすべく、ONNX の開発に取り組みます。

ONNX とは

ONNX はディープラーニングモデルをエンコードするためのオープンソース形式です。ONNX はニューラルネットワークの計算グラフ、グラフ内で使用される演算子の広範なリストの形式を定義します。拡大中のフレームワークリスト、ハードウェアベンダー、ディープラーニングの開発を手掛ける開発者などにサポートされている ONNX は、容易にフレームワーク間を移動し、目の前の課題に最適なフレームワークを選別することができます。

クイックスタート

今回は ONNX-MXNet を使用して MXNet に ONNX-MXNet をインポートする方法、そして推論用にインポートしたモデルを使用する方法をご紹介します。これにより、MXNet の最適化した実行エンジンのメリットを活用することができます。

ステップ 1: インストール

まず、ONNX repo の手順に従い、ONNX をインストールします。

次に ONNX-MXNet パッケージをインストールします。

$ pip install onnx-mxnet

ステップ 2: ONNX モデルを準備してインポート

この例では、イメージの空間分解能を高めるように設計されている Super Resolution モデルのインポートを行います。このモデルは PyTorch で構築とトレーニングが行われ、PyTorch の ONNX エクスポート API を使用して ONNX にエクスポートされています。モデル設計の詳細については PyTorch の例をご覧ください。

Super Resolution ONNX モデルを作業ディレクトリにダウンロードします。

$ wget https://s3.amazonaws.com/onnx-mxnet/examples/super_resolution.onnx

ステップ 3: ONNX モデルを MXNet にインポート

ONNX モデルのファイルの準備ができたので、ONNX-MXNet インポート API を使用して MXNet にインポートしてみましょう。Python シェルで次のコードを実行します。

import onnx_mxnet
sym, params = onnx_mxnet.import_model('super_resolution.onnx')

Python ランタイムで 2 つのインスタンスを作成しました。 sym – モデルのシンボリックグラフと params – モデルのウェイトです。これで ONNX モデルのインポートが完了し、標準の MXNet モデルができました。

(more…)

Scaling Your Amazon RDS Instance Vertically and Horizontally

Marie Yap はアマゾン ウェブ サービスのソリューションアーキテクトです。

Amazon RDSは、マネージド型サービスとして、リレーショナルデータベースのスケーリングを処理し、データベースがアプリケーションやアプリケーションの増加する要求に対応できるようにします。

このブログ記事では、RDS インスタンスを縦横に拡大縮小する方法について説明します。ほぼ同じ数の読み取りと書き込みを使用するアプリケーションの増加する要求に対応するために、垂直方向に拡大縮小することができます。また、読み取りが重いアプリケーションの場合は、水平方向に拡大縮小することもできます。

垂直スケーリング
データベースの高い負荷を処理するために、ボタンを押すだけでマスターデータベースを垂直方向にスケールアップできます。現在、RDS MySQL、PostgreSQL、MariaDB、Oracle、または Microsoft SQL Server インスタンスのサイズを変更する際に、18 種類以上のインスタンスサイズを選択できます。Amazon Aurora では、5 つのメモリ最適化インスタンスサイズを選択できます。インスタンスタイプを幅広く選択することで、データベースサーバーに最適なリソースとコストを選択できます。

以下は、RDS インスタンスをスケールアップする際の考慮事項です。

  • スケールを変更する前に、商用エンジン (SQL Server、Oracle) の正しいライセンスを取得していることを確認してください (特に、ライセンス持ち込み (BYOL) が必要な場合)。重要なことは、商用エンジンの場合はライセンスによって制限されていることです。ライセンスは、通常 CPU ソケットまたはコアに関連付けられています。
  • 変更をいつ適用するかを決めます。変更をすぐに適用するか、インスタンスで指定されたメンテナンス期間中に変更を適用するかを選択できます。
  • ストレージとインスタンスのタイプは切り離されています。データベースインスタンスを上下にスケールしたときは、ストレージサイズは同じままで、変更の影響を受けません。DB インスタンスを個別に変更して、割り当てられたストレージスペースを増やすか、ストレージタイプを変更して (一般目的 SSD からプロビジョニング IOPS SSD などに) パフォーマンスを向上させることができます。
  • スタンバイデータベースが最初にアップグレードされた後で、新しくサイズの変更されたデータベースでフェイルオーバーが発生するため、Multi-AZ 環境でスケールアップする場合のダウンタイムは最小限に抑えられます。シングル AZ インスタンスは、スケール操作中は使用できません。

インスタンスのタイプを変更するには、RDS コンソールの [インスタンスの操作] メニューから [変更] を選択します。

次に、新しい DB インスタンスクラスを選択します。

最後に、変更をすぐに適用するかどうかを決定します。変更をすぐに適用するには、[変更] ページの一番下にある [すぐに適用] チェックボックスを選択します。変更をすぐに適用しないと、定義した優先メンテナンスウィンドウ中に変更がスケジュールされます。

水平スケーリング
マスターデータベースを垂直方向に拡張するだけでなく、読み取りレプリカを使用してデータベースを水平方向に拡大することによって、読み取りが重いデータベースのパフォーマンスを向上させることもできます。RDS MySQL、PostgreSQL、MariaDB には最大 5 つのリードレプリカがあり、Amazon Aurora には最大 15 のリードレプリカがあります。

リードレプリカを使用すると、マスターデータベースと同期する読み取り専用コピーを作成できます。より良いパフォーマンスを得るために、リードレプリカをユーザーにより近い別の AWS Region に配置することもできます。また、リードレプリカをマスターに昇格させることで、リードレプリカを使用してデータベースの可用性を高め、災害時の迅速なリカバリーを行うことができます。ただし、リードレプリカは、Multi-AZ が提供する高可用性と自動フェイルオーバー機能の代替となるものではありません。

現在、RDS リードレプリカは、クエリまたは接続の透過的なロードバランシングをサポートしています。各レプリカには固有のドメインネームサービス (DNS) エンドポイントがあり、アプリケーションはレプリカエンドポイントに接続してロードバランシングを実装できます。では、アプリケーションで RDS リードレプリカを認識させる方法のオプションを見てみましょう。

アプリケーションがネイティブの MySQL ドライバを使用している場合は、アプリケーションに大きな変更を加えることなく、読み取り/書き込み分割と読み取り専用のエンドポイントロードバランシングを実行できる MySQL Connector があります。たとえば、PHP アプリケーションをお持ちの場合は、MySQL ネイティブドライバの PHP Mysqlnd レプリケーションとロードバランシングプラグインを使用できます。

MySQL Connector を使用することに加えて、アプリケーションとデータベースサーバの間にロードバランサを追加することができます。アプリケーションに単一のデータベースエンドポイントが表示されるように、この追加を行います。このアプローチでは、アプリケーションのデータベース接続文字列を絶えず更新することなく、ロードバランサの背後にあるリードレプリカを透過的に追加または削除できるより動的な環境が可能になります。また、スクリプトを使用してカスタムヘルスチェックを実行することもできます。

図に示すように、トランスポートまたはレイヤ 4 ロードバランサを MySQL Connector とともに使用できます。現在、Elastic Load Balancing (ELB) ロードバランサは、RDS インスタンスへのトラフィックのルーティングをサポートしていません。したがって、多くの人が使用するオープンソースのソフトウェアベースのロードバランサである HAProxy などのオプションを検討することもできます。このソリューションでは、1 つのポートで読み込みクエリを受信し、もう 1 つのポートで書き込みクエリを受信するように HAProxy を構成できます。

もう 1 つの選択肢は、レイヤ 7 の SQL 対応ロードバランサを使用することです。複雑なルールを使用してデータベースにクエリを転送することができます。このタイプのロードバランサは、マルチステートメントで読み書きスプリットを適切に実行する方法を理解する、MySQL Connector よりも洗練された機能を備えています。このソリューションは、分散データベース環境でスケーリングの問題を処理するため、アプリケーション層のスケーリングを処理する必要がないため、アプリケーション自体にはほとんど変更が加えられません。これを実現するには、MaxScale、ProxySQL、MySQL Proxy などのオープンソースソリューションと商用ソリューションがあります。そのうちのいくつかは AWS Marketplace にあります。

まとめ
要約すると、アプリケーションの増加するニーズに対応するために、RDS 構成を拡張または縮小することができます。RDS はデータベースのスケーリングに大いに役立つため、お客様はアプリケーションやアプリケーションにより集中できるようになります。

 

Amazon QuickSight の更新 – 地理空間の可視化、プライベートVPCアクセス、その他

AWSでは記念日を敢えて祝うことはあまりしません。100近いサービスによって、週に何度もアップデートを展開するのが当たり前になっています。(まるで週に何度もケーキを食べて、 シャンパンを飲んでいるようなものです。)それは楽しそうに聞こえますが、我々はむしろ、お客様に耳を傾け、イノベーションを起こすことに多くの時間を費やしています。とは言うものの、 Amazon QuickSight は一般提供開始から1年が経ちましたので、簡単にアップデートを紹介したいと思います!

QuickSight の事例

本日、数万のお客様(スタートアップからエンタープライズまで、交通や法律、鉱業、医療などの様々な業界)がお客様のビジネスデータの分析とレポートのためにQuickSightを利用されています。

幾つか例を上げましょう。


Gemini は負傷した労働者を弁護するカリフォルニア弁護士に法的根拠の調達サービスを提供しています。彼らは、カスタムレポートの作成や一度限りのクエリの実行から、ドリルダウンとフィルタリングを使用した動的なQuickSightダッシュボードの作成と共有までを行っています。QuickSightは、販売パイプラインの追跡、注文のスループットの測定、注文処理パイプラインでのボトルネックの特定に使用されています。

Jivochat はウェブサイト訪問者とウェブサイトの所有者とを繋ぐ、リアルタイムメッセージングプラットフォームを提供しています。QuickSightを使用して、彼らはインタラクティブなダッシュボードを作成・共有しながら、元となるデータセットへのアクセスも提供しています。これにより、静的なスプレッドシートを共有するにとどまらず、誰もが同じデータを見ていることを保証し、現時点でのデータに基づいてタイムリーな決定を下すことを後押ししています。

Transfix は、小売業、食品・飲料、製造業およびその他の業種のFortune 500に名を連ねるリテールの荷送主に、荷物にマッチする配送業者を選択でき、ロジスティクスの可視性を高める、オンライン貨物市場です。QuickSightはBIエンジニアと非技術系ビジネスユーザーの両方に分析環境を提供しています。彼らはQuickSightを通じて、輸送ルート、運送業者効率性、プロセス自動化などのビジネスの鍵となる事柄や運営指標を吟味しています。

振り返り / 先読み
QuickSightに対するフィードバックはとても役に立っています。お客様は、自社のBIインフラを設定または実行することなく、従業員がQuickSightを使用してデータに接続し、分析を実行し、データに基づいた高速な決定を下すことができていると教えてくれます。我々は頂いたフィードバックをすべて歓迎し、それを使用してロードマップを推進し、1年で40を超える新機能を導入してきました。以下はその要約です:

今後のことを考えると、お客様に興味深い傾向が見られます。データの分析方法やレポート方法を詳しく見ていくうちに、サーバーレスのアプローチがいくつかの目に見えるメリットをもたらすことに気づき始めるのです。彼らは、Amazon Simple Storage Service (S3) をデータレイクとして使用し、QuickSight と Amazon Athena のコンビネーションによってクエリを実行することで、静的なインフラストラクチャ無しに迅速で柔軟な分析環境を手にしています。また、QuickSightのダッシュボード機能を活用し、ビジネスの結果や運用メトリクスを監視し、数百人のユーザーと彼らの洞察を共有しています。もしこのようなアプローチに興味がある場合は、Building a Serverless Analytics Solution for Cleaner Cities のブログポストや、 Severless Big Data Analytics using Amazon Athena and Amazon QuickSight  のスライドを御覧ください。

新しい機能の追加と拡張
我々は、QuickSightが今後もお客様のニーズを満たすことを確認するために、お客様の声を聞き、それを学ぶことにベストを尽くしています。そして以下の7つの大きな機能をアナウンスできることを幸福に思います:

地理空間の可視化 – 位置情報データセットを地理空間に可視化することが可能になります。

プライベートVPCアクセス – VPC内、またはオンプレミスデータに対し、パブリックなエンドポイント無しにセキュアに接続できる新しい機能のプレビューに参加することができます。

フラットテーブルのサポート – ピボットテーブルに加えて、表形式レポート用のフラットテーブルを使用することができます。詳しくは Using Tabular Reports を参照ください。

SPICE上のデータに対して計算フィールドを適用する – SPICE上のデータに対して計算フィールドを適用することができます。詳しくは 分析への計算フィールドの追加 を参照ください。

ワイドテーブルのサポート – テーブルあたり1000カラムまで使用することができます。

「その他」をまとめて表示 – カーディナリティの高いロングテールデータを、「その他」としてまとめて表示することができます。詳しくは Amazon QuickSight でビジュアルタイプを使用する を参照ください。

HIPAA コンプライアンス – QuickSightでHIPAAコンプライアンス準拠のワークロードに対応できます。

地理空間の可視化
お待たせしました!地理的な識別子(国、都市、州または郵便番号)を含むデータから、数回のクリックで美しいビジュアルを作成できるようになりました。QuickSightはそれらのデータをマップ上の位置情報に変換しますし、緯度/経度にも対応しています。この機能を使用して、州ごとの売上を視覚化したり、店舗を配送先にマップしたりすることができます。視覚化のサンプルは次のとおりです。

詳しくは、Using Geospatial Charts (Maps) , と Adding Geospatial Data を参照ください。

プライベートVPCアクセスのプレビュー
もしあなたがAWS上(もしかすると Amazon RedshiftAmazon Relational Database Service (RDS)  、または EC2上かもしれません)または、パブリック接続の無いオンプレミス上のTeradataやSQL Serverにデータを保持している場合、この機能はあなたのためにあります。QuickSightのプライベートVPCアクセスは、ENIを使用してセキュアに、プライベートにVPC内のデータソースにアクセスします。AWS Direct Connect を使用してセキュアに、オンプレミス上のリソースにプライベートリンクを貼ることもできます。以下のような形です。

プレビューに参加する準備ができている場合、本日からサインアップ可能です。 

Jeff;

(翻訳:SA八木、元の記事はこちらです)

Amazon Polly が 9 つの対象 AWS リージョン、韓国語のサポート、新しいインド英語音声を追加

Amazon Polly は、テキストを生きた話し声に変換する AWS のサービスです。Amazon Polly に 9 つのリージョンが追加され、Polly が利用可能なリージョンの合計数が 14 となったことを発表いたします。さらに、韓国語サポートの開始、テキスト読み上げ機能ポートフォリオへのインド英語音声の追加を発表いたします。新しい韓国語の女性音声 Seoyeon、およびインド英語音声の Aditi をご紹介します。

Amazon Polly は、世界中のお客様に対して最大の安定性と最小のレイテンシーを提供するべく、以下の 14 の AWS リージョンで提供されます: アジアパシフィック (ムンバイ)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、南米 (サンパウロ)、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、および米国西部 (オレゴン)。

Amazon Polly は re:Invent 2016 で発表されて以来、最も多いリクエストの 1 つとして、追加言語のサポートがありました。お客様からの最も多くのリクエストがあった言語の 1 つが韓国語です。お客様の需要にお応えして、最初の韓国語音声 Seoyeon を発表いたします。

(more…)

AWS Deep Learning Conda と Base AMI の利用開始について

AWS は AWS Deep Learning AMI に Conda ベースの AMI と Base AMI という 2 つの新しいバージョンを利用可能にしたことを発表しました。このブログでは、新しい AMI を最大限に活用するための手順と追加リソースについてご説明します。

Conda マネージド型環境を取り入れた新しい Deep Learning AMI

Amazon LinuxUbuntu を対象にした新しい Deep Learning AMI には、人気のオープンソースパッケージと環境管理ツールである Conda を使用して作成したディープラーニング用の Python 環境がプリインストールされています。Conda マネージド型 Python 環境は、Apache MXNet、TensorFlow、Caffe2、PyTorch、Keras、CNTK、Theano を含む、人気のディープラーニングフレームワーク用に事前設定されています。また、Python 環境にはそれぞれ Python 2 と Python 3 が含まれています。AWS マネジメントコンソールを使用して AWS EC2 インスタンスにログインすると、Conda 環境すべてを含むリストがコンソールメッセージとして表示されます。

次のコマンドを実行すると、このリストを取得できます。

conda env list

次に、任意のディープラーニングフレームワーク、たとえば MXNet 用の Python 環境をアクティブ化するには、次を実行します。

For Python 2

source activate mxnet_p27

For Python 3

source activate mxnet_p36

Python 環境に入ったら、次のコマンドを実行してインストール済みのパッケージリストを表示することができます。

conda list

(more…)

Machine Learning ユーザー向けの新しい AWS Deep Learning AMI

この度、AWS Deep Learning AMI の新しい 2 つのバージョンの提供を開始しました。人気のオープンソースパッケージと環境ツールの Conda を使用して作成したディープラーニングフレームワーク用に別の Python 環境を使用する Conda ベースの AMI、そして独自のカスタマイズしたディープラーニングモデルをデプロイするための GPU ドライバとライブラリを使用する Base AMI です。

学会と業界の両方に渡り、ディープラーニングテクノロジーはフレームワーク、アルゴリズム、そして新しい方法や理論に渡り、急速に進化しています。そのため、素早く安全にアルゴリズムをテストしたり、フレームワークの特定のバージョンの最適化、テストやベンチマークの実行、新しく始めるプロジェクト開始の共同作業などにおいてツールを必要とする開発者達にとって複雑の原因になっています。そこで、AWS Deep Learning AMI においても、そうした自由と柔軟性を提供するために仮想環境を追加することにしました。また、新たに開発者用リソースもセットアップすることで、これまで以上に AMI の理解を深めたり、プロジェクトに適切な AMI を選択したり、ハンズオンチュートリアルを利用できるようにしています。

Conda ベースの Deep Learning AMI

Conda ベースの AMI は Conda を使用して作成したディープラーニングの Python 環境にプリインストールされています。各 Conda ベースの Python 環境は、人気のディープラーニングフレームワークの公式 pip パッケージと、その依存関係を含むように設定されています。たとえば、ニューラルネットワークモデルをトレーニングするためのディープラーニングコードを実行する準備が整い、完全に仕上がった仮想環境とお考えください。ステップバイステップガイドでは、任意のディープラーニングフレームワークを使用した環境をアクティブ化する方法や、シンプルな 1 行のコマンドを使用して環境を切り替える方法について説明しています。

AMI のメリットは他にもあります。AMI の環境は相互に孤立した自己完結型のサンドボックスとして稼働します。つまり、サンドボックス内でディープラーニングのコードを実行すると、実行時の環境を完全に見通し全体的に管理することができます。AMI の他のディープラーニング環境を中断してしまう心配なく、新しいソフトウェアパッケージをインストールしたり、既存のパッケージのアップグレードや環境変数を変更することができます。実行環境でこのレベルの柔軟性と詳細管理を行えるということは、一貫性のある再生可能な方法でディープラーニングモデルのテスト実行やパフォーマンスのベンチマークが行えることを意味しています。

最後に、AMI は Jupyter ノートブックに直接プラグできるビジュアルインターフェイスを提供するので、Jupyter ノートブックのブラウザからクリック 1 回で環境を切り替えたり、任意の環境でノートブックを起動したり、環境を再設定することができます。ステップバイステップガイドでは、こうした統合と Jupyter ノートブックやチュートリアルについて説明しています。

(more…)

New – AWS OpsWorks for Puppet Enterprise

昨年開催された AWS re:Invent で AWS OpsWorks for Chef Automate を公開しました。これはユーザーが AWS マネージド型の独自の Chef Automate サーバーを利用できるようにするものです。そして、ユーザーからのフィードバックを元に構築した Puppet Enterprise を OpsWorks に追加しました。

Puppet Enterprise は、管理されている各ノードでデプロイした puppet-agent を介してプロビジョニング、設定、インスタンスの管理を自動化できるようにします。設定は 1 回定義することができ、自動ロールバックとドリフト検出で何千件ものノードに適用することができます。AWS OpsWorks for Puppet Enterprise は、既存の Puppet マニフェストでシームレスに連動させながら、独自の Puppet マスターを管理する必要を排除します。

OpsWorks for Puppet Enterprise は、ユーザーの代わりに Puppet マスターサーバーを管理し、インストール、アップグレード、バックアップといった運用タスクを行います。また、ノード登録を簡素化したり、ノードのブートストラップの便利なスターターキットも提供しています。詳細については次をご覧ください。

Managed Puppet Master の作成

OpsWorks で Puppet マスターを作成するのは簡単です。まず、OpsWorks コンソールの [Puppet] セクションにアクセスし [Create Puppet Enterprise Server] をクリックします。

セットアップのこの段階では、Puppet マスターのリージョンと EC2 インスタンスタイプを設定します。c4.large は最大 450 件のノードをサポート、c4.2xlarge は 1600+ 件のノードをサポートします。Puppet Enterprise サーバーは Amazon Linux (2017.09) の最新バージョンと Puppet Enterprise (2017.3.2) の最新バージョンでプロビジョンされます。

次のセットアップ画面で、SSH キーが Puppet マスターに接続するようにオプションで設定することができます。これは大規模なカスタマイズを行う場合に便利ですが、インスタンスから直接操作を行うのではなくクライアントツールを介して Puppet を操作する方が一般的に優れた方法です。

また、このページでは動的設定を行うために r10k repo をセットアップすることもできます。

「Advanced Settings」ページで VPC、セキュリティグループ、IAM ロール、インスタンスプロフィールなどに、いつものデプロイオプションを選択できます。OpsWorks にインスタンスセキュリティグループを作成させるとデフォルトで開かれた状態になるため、後でアクセス制限を設定することが重要になります。

このページで注意したい 2 つのコンポーネントは、メンテナンスウィンドウとバックアップ設定です。Puppet ソフトウェアの新しいマイナーバージョンが利用可能になると、システムメンテナンスは AWS テストが完了次第、Puppet マスターにある Puppet Enterprise のマイナーバージョンを自動更新するように設計されています。AWS は Puppet のアップグレードが本番稼働で利用できるものか確認するため広範囲に渡るテストを行い、ユーザーの既存環境を中断せずにデプロイします。自動バックアップは S3 で Puppet マスターの耐久性に優れたバックアップを保存し、いつでもそのバックアップから復元を行うことができます。ご自分のビジネスニーズに合わせて、バックアップの頻度と保持期間を調整することができます。

Puppet Enterprise で AWS OpsWorks を使用

Puppet マスターをプロビジョンしている間に、コンソールで便利な情報が 2 つ表示されます。

サインイン認証情報と Windows や Linux ノードにインストールする Puppet エージェントのサンプルユーザデータをダウンロードすることができます。ここで重要なのは、Puppet マスターに接続できる限り、オンプレミスノードも管理できることです。

Puppet マスターのプロビジョンが完了したら、Puppet Enterprise の HTTP コンソールにアクセスし、通常どおり Puppet を使用することができます。

詳細情報

AWS OpsWorks for Puppet Enterprise の料金は管理されているノードのノード時間を元に請求されます。料金は 0.017 USD / ノード時間で、ノードのボリュームで低下します。詳細についてはこちらのページをご覧ください。また、Puppet マスターの実行に必要な基盤となるリソースも請求されます。現在、AWS OpsWorks for Puppet Enterprise は米国東部 (バージニア北部) リージョン、米国西部 (オレゴン) リージョン、欧州 (アイルランド) リージョンでご利用いただけます。もちろん、コンソールに表示されているものはすべて AWS SDK や CLI でも行うことができます。詳細については「入門ガイド (Getting Started Guide)」をご覧ください。

Randall