よくある質問集 | AWSアカウント作成＆利用ガイド | 無料使用枠 | 事例パンフレット | 営業お問い合わせ | 見積もりツール| クラウドWebinar資料| AWSホーム | AWSプレミアムサポート | 日本語フォーラム | ユーザーグループ | エバンジェリストへの講演依頼
最近の記事
- 【AWS発表】 Amazon SimpleWorkflow - クラウドベースのワークフロー管理サービス
- AWSユーザーグループ(JAWS) のサミット 3月2日~3日に開催！
- 【AWS発表】 Amazon S3の価格さらに値下げ
- 【AWS発表】 Elastic MapReduceの新機能：メトリクス、Hadoopのアップデート、VPC、そしてクラスタコンピュートのサポート
- 【AWS発表】 AWS プレミアムサポートに新機能: サードパーティ製ソフトウェアサポート(英語のみ)とAWS Trusted Advisor
- 【AWS発表】 Auto Scaling Groupがタグをサポート
- 【AWS発表】 大阪にAmazon CloudFrontとAmazon Route 53の拠点追加
- Amazon S3に保存されているオブジェクトの数は7620億
- 【AWS発表】 AWS Storage Gatewayの発表。既存のオンプレミスアプリケーションをAWSのクラウドストレージに自動バックアップ
- 【AWS発表】 Virtual Private Cloudの中でRelational Database Serviceが利用可能に
【AWS発表】 Amazon SimpleWorkflow - クラウドベースのワークフロー管理サービス
今回の発表は、Amazon Simple Workflow、略してSWFという新サービスです！このサービスは、複数のシステム（クラウドのシステムであれ、オンプレミスのものであれ）に分散した耐障害性の高いアプリケーションを構築することを可能にするサービスです。 Amazon Simple Workflowは、同期型、非同期型のタスク（論理的なアプリケーションのステップ）のフローをコントロールするサービスです。このサービスを使うことにより、ユーザーは、インフラではなく、ビジネスやアプリケーションに集中することができます。
SWF登場の背景
AWSは、分散型で耐障害性の高いクラウドアプリケーションの作成をより簡単にしたいと常に考えています。AWSの内部でそのようなシステムを分散型アプリを構築してきた経験から、次のようなことを学んできました。
- アプリケーションは大抵の場合ワークフローを含む -- この場合、一連のステップが定義された順番で行われる必要があり、意思決定や特殊なケースの扱いのために、ワークフローを調整するが多々あります。
- ワークフローは多くの場合ビジネスプロセスを表現している - 例えば、人気Eコマースサイトの例をみてみましょう。クレジットカードへのチャージ、注文履歴の更新、配送される商品の調整、商品の配送、配送状況のトラック、在庫の補充、返送品の扱い、などなどがあります。
- ビジネスプロセスは複雑である - 数年ほど前、Amazon.co.jpでの一つの注文は、完了するまでに40以上のステップを経ている、と聞いたことがあります。最近はさらに複雑になっているに違いありません。
- 柔軟性が大事 - これまでのワークフローソリューションは、柔軟性が無いことが課題でした。
- 簡単に使えることが必要 - こういったアプリケーションを、特殊なスキルを学習することなく、設計、実装できるとどれだけ便利でしょうか。
Simple Workflowを利用することで、既存のビジネスプロセス（注文の処理や従業員の新規追加など）だけでなく、例えば、複雑なマルチティア・アプリケーションや、マルチプレイヤー型オンラインゲームの意思決定プロセスの処理、といった多種のワークフローをより簡単に取扱うことができます。
用語集とサンプル
ここで、幾つかの用語を定義しましょう。
- ワークフロー (Workflow)は、ビジネスプロセスを自動化したもの。
- ドメイン (Domain)は、関連するワークフローをまとめる概念です。
- アクション (Action)は、ワークフローを実行するのに行われる個別のタスクです。
- アクティビティワーカー (Activity Worker)は、タスクを実際に実行するものです(コードの集合)。各種のワーカーはアクションタイプ (Activity Type)を持ちます。
- ディサイダー (Decider)は、ワークフローを調整するロジックを持ちます。
ここで、画像処理のワークフローを例とって、タスクを考えてみます。
- アップロードしたファイルの受付け
- Amazon S3へのファイル保存
- ファイルフォーマットとサイズの確認
- 画像の分類にAmazon Mechanical Turkを利用
- もし画像が受け入れられない者の場合は、Amazon SESを用いてエラーメッセージを送付し、ワークフローを終了
- もし画像が受け入れ可能であれば、会計システムでユーザーの残高照会
- EC2インスタンスを起動
- EC2インスタンスの準備を待ち設定する(キー、パッケージ等)
- 画像をPNGフォーマットに変換し、イメージのサムネイルを作成
- PNG画像とサムネイルをS3にアップロード
- 会計システムでユーザーの残高を調整
- 適切なデータベースにエントリーを作成する
- Amazon SESを用いて、ユーザーに通知メッセージを送る
1から13のステップがワークフローです。各タスクはアクションと呼びます。各アクションを実装したコードが、特定のアクティビティワーカーの中に埋め込まれます。
ワークフローのディサイダーは、タスクからタスクへの実行フローをコントロールするのにつかわれます。上記の場合は、ステップ4(Mechanical Turk)から、ステップ5(SES)もしくはステップ6(残高照会)のところで、判断に使われています。
Simple Workflowは何をしてくれるのか?
Simple Workflowは、上記のようなワークフローを実装するためのインフラストラクチャを提供します。Simple Workflowは下記の機能を提供します(下記以外の機能もあります！)。
- ワークフローと各部品についてのメタデータを保存します
- ワーカーのためのタスクを保存し、ワーカーがそれを必要とするまでキューイングします
- タスクをワーカーにアサインします
- ワークフローの実行と、関連するワーカーの間で、情報をルーティングします
- タスクにおけるワーカーの進行状況をトラックし、タイムアウト設定も可能です
- 冗長的にワークフローの状態を維持します
ワーカーとディサイダーはステートレスなので、急増するトラフィックに対しても、必要に応じて、単純に追加のワーカーとディサイダーを追加できます。これはもちろん、AWSクラウドのAmazon EC2インスタンスを用いている場合は、Auto Scalingを用いることで追加や削減を容易に行えるでしょう。
ワーカーやディサイダーはどのようなプログラミング言語で書くこともできます。そして、それをクラウドに稼働することも(Amazon EC2インスタンスなど)、オンプレミスのデータセンターでも、場合によってはみなさんのデスクトップコンピュータでも構いません！ワーカーとしては単純に、Simple Workflowのタスクをポーリングして、それをとってきて、実行した結果を戻すだけです。言い換えれば、コードそのものはどこで走らせていても、Amazon Simple WorkflowのHTTPSのエンドポイントを見ることができさえすれば良いのです。これによって、既存のオンプレミスのシステムを、容易に、新しいクラウドベースのワークフローにつなぎ込む柔軟性を手に入れられます。Simple Workflowは、"ロングポーリング (long polling)"を用いて、ネットワークトラフィック削減し不必要な処理量を減らすことも可能です。Simple Workflowが、リクエストからタスクが発生するまでレスポンスを返すのを60秒まで保留することができます。
ディサイダーの中身
ディサイダーのコードは単純に、判断部分においてSimple Workflowをポーリングし、その判断を行い、次のステップへすすめます。 コードからは、判断において必要なすべての情報にアクセスできます。ワークフローの種類やワークフローの中で事前に行われたステップの履歴などが取得できます。またディサイダーは追加のデータをワークフローに付加することも可能です。
ワーカーの中身
ワーカーの中のコードも、単純にSimple Workflowをポーリングして行うべき仕事を取得します。一つ以上のタスクリストをポールすることができるので、ワーカーは複数の種類のワークフローに参加することもできます。タスクリストから仕事をとり、それを処理し、ワークフローのステータスを更新し、次のタスクにとりかかります。長く時間のかかるタスクを行う場合は、ワーカーはハートビートをSimple Workflowに更新することもできます。ディサイダーは、監査目的やチェックのために、ワークフローの実行履歴にマーカーを挿入することも可能です。
タイムアウト、シグナル
Simple Workflowはワークフローの正常に実行されるように、タイムアウトを用いることができます。 各種のタイムアウトがあります。
- Workflow Start to Close - 実行にかかる時間
- Decision Task Start to Close - ディサイダーが判断するのにかかる時間
- Activity Task Start to Close - アクティビティワーカーがタスクを処理するのにかかる時間
- Activity Task Heartbeat - アクティビティワーカーがステータス更新を行わないまでの時間
- Activity Task Schedule to Start - もしタスクを実行するワーカーがいないときに、Simple Workflowがタイムアウトするまでどらくらいの時間待つか
- Activity Task Schedule to Close - タスクがスケジュールされてからそれが完了するまで、Simple Workflowがタイムアウトするまでどらくらいの時間待つか
シグナルは、実行しているワークフローに情報を提供するのにつかわれます。ワークフローをキャンセルしたり、必要なデータが準備できていることを知らせたり、緊急の際に情報を提供する、といったことに使えます。各シグナルは、ワークフローの実行履歴に追加され、ワークフローのディサイダーは次に何を行うかコントロールできます。
Simple Workflowは、ワークフローがスタックするのをタイムアウトを用いることで、予定通りに実行されるようにします。
はじめてみよう
Amazon Simple Workflowをはじめてみるには下記の手順をとります。
- ご希望のプログラミング言語でワーカーを記述します
- ディサイダーを書きます(ご希望の言語で！)
- ワークフローとアクティビティを登録します
- ワーカーとディサイダーをご希望のホストで走らせます(Simple Workflowのエンドポイントが見えるホスト であれば何でも)
- ワークフローの実行を開始します
- ワークフローの進行状況をAWS Management Consoleで監視します
AWS Flow Framework
Amazon Simple Workflowをより簡単に扱えるように、AWS SDK for JavaはAWS Flow Frameworkに対応しています。 このフレームワークはタスク調整の詳細を抽象化する多種の部品をを含んでいます。例えば、Futureに基づいたプログラミングモデルを用いることで、タスク間の依存を扱うことができます。ワーカーのタスクを起動するのは、関数コールと同じように簡単に取り扱え、フレームワークがワーカーとディサイダーのタスクをケアしてくれます。
AWS Management Consoleのサポート
AWS Management Consoleは、Amazon Simple Workflowを完全にサポートしています。こちらが、メインページからのスタート画面です。
ワークフロードメインの登録。
ワークフロードメインに対して、ワークフローを登録します。
ワークフローの中にアクティビティを登録します。
ワークフローの実行を開始設定をします。
実行の際の入力データをインプットします。
与えられたワークフローで現在実行しているものを見ます。
Simple WorkflowのAPI基礎
ワークフロー、ワーカー、ディサイダーの作成もいくつかのSimple Workflow APIで行えます。
- ワークフローの登録 - RegisterDomain、RegisterWorkflowType、RegisterActivityTypeコールが用意されています。
- ディサイダーとワーカーの実装 - PollForDecisionTask、RespondDecisionTaskCompleted、PollForActivityTask、RespondActivityTaskCompletedコールが用意されています
- ワークフローの開始 - StartWorkflowExecutionコールが用意されています
詳細は、Amazon Simple Workflow API Referenceをご参照ください。
料金
他のサービスと同様、Amazon Simple Workflowも安価な従量課金で提供しています。最初にはじめるのは無料です。毎月1,000ワークフロー、10,000タスク、合計で 30,000 ワークフロー・日、利用できます(1日に1ワークフローがアクティブな場合、1ワークフロー・日となります)。
それを超えた場合は、下記の3つの観点で料金が計算されます。
- 実行 - ワークフローの1実行あたり、$0.0001で、 24時間以上アクティブになっている場合は追加で$0.000005かかります。
- タスク、タイマー、シグナル、マーカー - 各タスクの実行、タイマー、シグナル、マーカーあたり $0.000025。
- 帯域 - 通常のAWSの利用料金が加算されます。
いかがでしょうか？現在は東京リージョンは使えず、米国東リージョンのみとなっていますが、日本からも使えるので是非使ってみてください！
玉川憲 (@KenTamagawa)
【AWS発表】 Elastic MapReduceの新機能：メトリクス、Hadoopのアップデート、VPC、そしてクラスタコンピュートのサポート
本日は、EMRに関する新発表です。元記事は、EMRのプロダクトマネージャのアダム・グレイが書いています。今回の日本語版ブログは、ソリューションアーキテクトの大谷晋平(@shot6)が書いています！
-- 玉川憲 (@KenTamagawa)
AWSは、皆様がお持ちのデータからより簡単に価値を引き出せるような機能を提供する事に、いつも喜びを感じています。そのため、沢山の新発表をリリースできる今回はEMRチームにとっても非常にエキサイティングです。EMRチームが最近提供した機能のうち、幾つかを見ていきましょう。
CloudWatchのメトリクス提供
本日より、お客様はEMRコンソールのジョブフロー詳細ページ内にあるモニタリングタブを選択して、23ものジョブフローメトリクスのグラフを見ることが出来ます。このメトリクスはCloudWatchによって無料で5分ごとに提供され、以下のような情報を参照できます。
- ジョブフロー内のmap及びreduceタスクの実行数、残りのタスク数、S3とHDFSの読み書きしたバイト数を含むジョブフローの進行具合。
- HDFS利用率、mapとreduceのスロットオープン数、稼働ジョブ数、残mapタスクとmapのスロット数の比率を含むジョブフローの状況。
- ジョブフローがアイドル状態か、データブロックの欠損、またはデッドノードがないかなどのジョブフローの健康状態。
EMRコンソール内でCloudWatchのグラフがどのように可視化されるかは下記のビデオをご覧ください(英語)。
EMR Developer GuideのViewing CloudWatch MetricsでCloudWatchの利用について更に学ぶことが出来ます。EMRの新しいメトリクスはAWSマネージメントコンソールから参照出来ます。
更に、CloudWatchコンソール、API、SDKを介してメトリクスに対してある特定の閾値を超えたかどうかをSNS経由で通知を受け取るアラームを設定できます。例えば、ジョブフローが30分以上アイドルかどうか、HDFSの利用率が80%を超えたか、mapタスクのスロットに対してmap残タスクが5倍以上あるなど、たとえば、クラスタサイズの拡張をしたい際にその兆候をメールで受け取ることが出来ます。
以下のビデオでCloudWatchコンソールでEMRのアラームをどのようにセットするかを学べます。
Hadoopアップデート：Hadoop 0.20.205、Pig 0.9.1、AMIバージョニング
EMRはHadoop 0.20.205とPig 0.9.1をサポートします。また、アップグレードのプロセスを単純化するため、AMIバージョニングを導入しました。ジョブフロー起動時にAMIのバージョンを指定して利用、または"最新"のAMIを指定する事でお客様がEMRの最新機能を常に使うことが出来ます。利用な可能なAMIバージョンとしては下記のとおりです。
- Version 2.0.x: Hadoop 0.20.205, Hive 0.7.1, Pig 0.9.1, Debian 6.0.2 (Squeeze)
- Version 1.0.x: Hadoop 0.18.3 または 0.20.2, Hive 0.5 または 0.7.1, Pig 0.3 または 0.6, Debian 5.0 (Lenny)
AMIバージョンは、Ruby CLIを使う場合、--ami-version引数でジョブフロー起動時に指定することが出来ます(最新のRuby CLIをダウンロードする必要があります。
$ ./elastic-mapreduce --create --alive --name "Test AMI Versioning" --ami-version latest --num-instances 5 --instance-type m1.small
詳細はAmazon Elastic MapReduce Developer GuideのAMI Versioningを参照してください。
S3DistCpを使ったS3とHDFS間の効率的なコピー
また、今回の発表に伴い、S3DistCpをサポートしました。Apache DistCpはオープンソースの分散データコピーツールで、Amazon S3に最適化されたApache DistCp拡張です。S3DistCpを使うことで、Amazon S3とAmazon EMRジョブフロー上のHDFSとの間で、またはS3バケット間で、膨大な量のデータを効率的にコピーすることが出来ます。またデータコピー中にHadoopで処理しやすいようにファイルの最適化を行う事も出来ます。これは圧縮スキーマの修正や、小さいファイルの連結、パーティションの作成などを含んでいます。
例えば、Amazon CloudFrontのログをS3からHDFSにロードする最中に、同時に圧縮フォーマットをGzip(CloudFrontのデフォルト)からLZPに変更したうえで、指定の時間内の全てのログファイルを1つのファイルにまとめる事が出来ます。Hadoopジョブは、大量にある小さいサイズのGzipファイルよりも、数が少なく巨大でLZOで圧縮されたファイルの方が効果的に処理できるため、パフォーマンスの劇的な向上が見込めます。
Amazon Elastic MapReduce Developer GuideのDistributed Copy Using S3DistCp で詳細やコードサンプルも見てみてください。
cc2.8xlargeサポート
Amazon Elastic MapReduceはAmazon EC2クラスタコンピュートインスタンスである、Cluster Compute Eight Extra Large (cc2.8xlarge)をサポートしました。他のクラスターコンピュートインスタンス同様、cc2.8xlargeインスタンスはハイパフォーマンスコンピューティング用途に特化しており、お客様に非常に高いCPU性能と、高帯域・低レイテンシ・フルバイセクションなネットワークを持つインスタンスの起動を可能にします。cc2.8xlargeインスタンスは最初のクラスターコンピュートインスタンス(cc1.4xlarge)の2.5倍のCPU性能、増強したメモリとローカルストレージを持ち、非常に競争力のある価格で提供しています。詳細はAmazon Elastic MapReduceのInstance Typesセクションをご覧ください。
更に、cc1.4xlargeインスタンス利用時のAmazon Elastic MapReduceの価格を18%値下げし、1時間当たりの総コストを$1.57としました。詳細はAmazon Elastic MapReduce Pricing Pageをご覧ください。
VPCサポート
最後に、Amazon Virtual Private Cloud(Amazon VPC)でEMRジョブフローが実行できるようになりました。これにより、以下のことが可能になります。
- センシティブなデータの処理 - Amazon VPC内でのジョブフローの起動は、お客様のプライベートネットワーク上でのジョブフローの起動と似ています。VPCの中で起動するので、ネットワークへ誰がアクセス可能かを定義するルーティングテーブルやネットワークACLなどを追加の機能として利用できます。EMRジョブフローでセンシティブなデータを処理する場合には、このようなVPCのアクセスコントロールがより有用になるでしょう。
- インターナルネットワーク内のリソースへのアクセス - お客様のプライベートネットワークにデータがある場合、お客様によってはAWS上のAmazon Elastic MapReduceへデータを定期的にインポートすることは非現実的であったり、避けたいと思われるかもしれません。。原因としては、データの機密性などが考えられます。。VPCのサポートにより、このような場合はAmazon VPC上にジョブフローを起動し、VPNコネクションを通じてお客様のデータセンターに直接接続可能になりました。
VPC内でのAmazon Elastic MapReduceジョブフローはRuby CLIで--subnet引数を使ってサブネットアドレスを指定する事で起動できます(最新のRuby CLIをダウンロードする必要があります)。
$ ./elastic-mapreduce --create --alive --subnet "subnet-identifier"
詳細は、Running Job Flows on an Amazon VPCをご覧ください。
大谷晋平(@shot6)
【AWS発表】 AWS プレミアムサポートに新機能: サードパーティ製ソフトウェアサポート(英語のみ)とAWS Trusted Advisor
今回の発表により、AWS Premium Supportのゴールドレベルとプラチナレベルに新しいサポート内容を加えました。下記のものがベータとして提供されます。
- サードパーティ製ソフトウェアサポート（英語のみ） - EC2上で稼働する、最も広く使われているオペレーティングシステムに関してプレミアムサポートに直接問い合わせることができます。またシステムソフトウェアに関してもサポートいたします(詳細下記)。日本語でのサードパーティ製ソフトウェアサポートはまだはじまっておりませんが、計画をしておりますので、しばしお待ちください。
- AWS Trusted Advisor - AWS利用状況を監視し、コスト削減、システムパフォーマンス改善、またはセキュリティギャップを縮める機会があれば、構成変更や新サービスをお客様にお報せします。
サードパーティ製ソフトウェアサポート(英語のみ)
Microsoft Windows、Ubuntu、Red Hat Linux、SuSE Linux、Amazon Linux AMIを含む広く使用されているオペレーティングシステムに関して、プレミアムサポートに問い合わせることができます。また、ApacheやIIS webサーバ、Amazon SDK、Sendmail、Postfix、FTPを含むシステムソフトウェアに関しても問い合わせることができます。AWS サポートエンジニアが、これらのコンポーネントのセットアップ、構成、およびトラブルシューティングの一般的な問題に対処します。
また、デスクトップ共有ツールを利用することで、必要に応じて、お客様のデスクトップを共有してサポートすることも可能です。
AWS Trusted Advisor
AWS Trusted Advisorは、数十万のAWSのお客様にご利用頂いてきた経験を活かして、ベストプラクティスを提供するものです。AWS利用状況を監視し、コスト削減、システムパフォーマンス改善、またはセキュリティギャップを縮める機会があれば、構成変更や新サービスをお客様にお報せします。初回である今回のリリースでは、8つのエリアでチェック項目を設けています。この項目については、今後も拡充していく予定です。
チェック項目は、3つのグループに分けられます。フォールトトレランス・チェック、セキュリティ監査、コスト最適化です。
- セキュリティグループ (Security Group) - Openポート - このチェックは、セキュリティグループをチェックして、各ポートの空き状況に応じて、3つのカテゴリに分類します。GreenポートはSSH、HTTP、Redポートは通常はインターネット上に対してオープンにする必要が無いポート(例: Microsoft SQLのための1443ポート)、そしてそれ以外はYellowに分類します。
- セキュリティグループ(Security Group) - CIDRルール - セキュリティグループのCIDRルールをチェックして、必要以上にアクセスを許可していないかチェックします。しばしば(私も含めて)、 "/0"、 "/32"と間違えて設定していることがあります。
- リザーブドインスタンスの推奨 - こちらは、利用履歴などをチェックして、リザーブドインスタンスを用いてコスト最適化ができる場合はそちらを推奨します。
- Elastic IPアドレスの利用 - EC2インスタンスに関連づけられていないElastic IPアドレス (固定IPアドレス)をチェックします。利用しておらず、課金されるケースを避けるためです。
- EBSスナップショット - EBSをチェックし、スナップショットを一つも持たない、もしくは一つしか持たないものがあるかチェックします。Red/Yellow/Greenモデルがこちらでも使われます。Redは一つも持たない、もしくは、最近のものが非常に古い場合。Yellowは最近のスナップショットが古い場合、Greenは最近のスナップショットが比較的新しい場合です(閾値については、現在もまだ微調整中です)。
- Amazon EC2 アベイラビリティゾーン バランス - これは、EC2インスタンスが適切にアベイラビリティゾーンに分散されているかチェックします。Red/Yellow/Greenモデルがこちらでも使われ、Redは全てのインスタンスが一つのアベイラビリティゾーンに存在する場合に使われます。
- Elastic Load Balancerの最適化 - このチェックは各ロードバランサにおいて、アベイラビリティゾーンに適切にインスタンスが配分されているかチェックします。
- サービスリミット - こちらは、各アカウント毎のインスタンス数、Elastic IPアドレスや他のサービスに関するリミット(制限数)をチェックします(このリミットはフォーム申請することで適宜、解除できます)。
上記すべてのチェックが既存のAWS APIコールを用いて実装されています。AWS Trusted Advisorは、ユーザのデータに対するアクセスは全くありません。こちらは、AWS Trusted Advisorのコンセプト図です。
AWS Trusted Advisorによるアドバイスは、様々な形式で行われます。ある場合は、サポートエンジニアが、あるチェックが改善点を見つけたことを、サポートケースでお知らせいたします。また、お客様がサポートコールをかけられたときに、AWS Trusted Advisorの推奨事項をレビューすることも可能です。将来的には、スコアカードやWebコンソール(チェックの状況閲覧、起動、カスタマイズ、等)を利用できるようにしたいと考えています！
玉川憲 (@KenTamagawa)
【AWS発表】 大阪にAmazon CloudFrontとAmazon Route 53の拠点追加
大阪の皆様、お待たせいたしました。大阪(Osaka)にAmazon CloudFront（コンテンツ配信サービス）、Route 53（名前解決サービス）の拠点（エッジロケーション）が追加されました！
2011年は、Amazon CloudFront、Route 53の拠点を7か所追加しました。今回の発表では、Osakaに加え、イタリアのミラノ (Milan) に拠点が追加されています。これで、合計26か所のエッジロケーションを利用して、コンテンツ配信、名前解決を行うことができます。
今年度も、さらに新しい拠点追加を予定しております。エッジロケーション追加のサーベイも行っておりますので、ぜひご参加ください！希望の拠点を下記のように入力できるようになっております。
昨年3月の東京リージョンで主要AWSサービスが使えるようになり、エッジロケーションも東京に加え大阪に出来たことでますます便利になっております。是非、AWSクラウドをお使いください！
玉川憲 (@KenTamagawa)
Amazon S3に保存されているオブジェクトの数は7620億
2011年の終わりで、7620億(762,000,000,000)のオブジェクト(S3に保存される単位。ファイルのようなもので、1オブジェクトあたり最大5TBまで)がAmazon S3に保存されています！ また、ピーク時には、オブジェクトに対して、50万(500,000)リクエスト/秒がありました。
こちらは、Amazon S3に保存されているオブジェクト数の伸び状況を示したものです。
2011年は2010年と比較すると、約3倍(192% の伸び)になっています。昨年は、2006年のAmazon S3のサービス開始以降、最大の伸びを示したことになります。
S3の成長にあわせてAWSの組織もどんどん成長しています！AWSも人材を募集していますので、興味がある方は是非こちらや、空ポジション(2012年1月時点)をご参照ください。
玉川憲 (@KenTamagawa)
【AWS発表】 AWS Storage Gatewayの発表。既存のオンプレミスアプリケーションをAWSのクラウドストレージに自動バックアップ
注意: もし、皆様が(オンプレミスの)データセンタを利用していなかったり、すでにすべてのITインフラをクラウドにのせている場合は、このブログポストを読む必要はありません。しかし、興味がありそうな人がいましたら、是非転送してください(笑)。
Storage Gatewayとは
今回発表するAWS Storage Gatewayを用いると、既存のオンプレミス上のアプリケーションのデータを、AWSのクラウドストレージであるAmazon S3上に、スムーズに安全に統合することができます。そうすることで、S3が持つ、安価で高い耐久性(99.999999999%)を持ったストレージ性能を活かしたバックアップが可能です。バックアップされたデータから、いつでもオンプレミスのハードウェアの上にデータを復旧できます。
下記のStorage Gateway紹介ビデオをご覧ください(Youtubeの下部の『CC』をクリックすると、日本語のキャプションを設定できます)
また、Amazon S3に保存される際に、そのデータ形式は、クラウド上の仮想ディスクであるAmazon EBSのスナップショットとして保存されます。つまり、オンプレミスにデータを復旧するだけでなく、Amazon EBSのボリュームとして、クラウド上で復元することもできます。これは、データのみならず、オンプレミスのシステム(サーバー等を含む)事態に障害が起こった際にも、システム全体をクラウド上で復旧できるということを意味します。必要な時に、クラウド上に仮想サーバAmazon EC2を起動しEBSボリュームを付加すれば良いのです。さらに、Storage Gatewayを、オンプレミスからEC2上のアプリケーションへのデータ移行のために利用することもできるでしょう。
AWS Storage Gatewayの概念図がこちらです。
まず、AWS Storage Gatewayは、ソフトウェアアプライアンス(仮想マシンイメージ)としてAWSからダウンロードできます。既存データセンターの物理サーバーに仮想マシンのハイパーバイザーを準備し、ソフトウェアアプライアンスであるAWS Storage Gatewayを導入するだけで良いのです。
そうすると、AWS Storage GatewayのストレージボリュームはiSCSIのデバイスとして、オンプレミスの既存アプリケーションサーバにアタッチできます。既存のアプリケーションにほとんど手を加えることなく、データボリュームとしてAWS Storage Gatewayを利用できます。このストレージボリュームに書き込まれたデータは、スナップショットとしてAmazon S3に自動的にアップロードしてバックアップとして保存されます。これにより、データに対する高いアクセス性能を保ちつつ、耐久性の高いオフサイトのバックアップを可能にします。
ゲートウェイは、直接AWSにコネクトすることもできますし、ローカルプロキシーを介してコネクトすることもできます。AWS Direct Connect(AWSの専用線接続サービス）を利用するこもできます。また、各ゲートウェイで利用されるインバウンド、アウトバウンドの帯域の量をコントロールすることも可能です。全てのデータがアップロードの前に圧縮されます。
各ゲートウェイは、最大12ボリューム、合計で最大12TBのストレージをサポートします。各AWSアカウント毎に複数のゲートウェイを作成することができ、データの保存先は、世界の5か所のリージョンから選択することができます（東京、シンガポール、米国東、米国西、ヨーロッパの各リージョン）。
今回のAWS Storage Gatewayの最初のリリースでは、VMware ESXi 4.1形式のVMイメージで提供されます（今後は、他の形式も予定しています）。適切な量のローカルのディスクストレージ（直結されたものでも、SANのもの）が必要となり、それらは、アプリケーション用ストレージ（iSCSIストレージボリュームにより使われる）と、作業用ストレージ（AWSへ書き込み用にキューされたデータ）として使われます。このiSCSIストレージボリュームのマウントには、Microsoft Windows Initiator形式と、RedHat iSCSI initiator形式をサポートしています。
パッチの自動インストール、スナップショット管理
一度インストールされると、各ゲートウェイはアップデートやパッチを自動的にダウンロード、インストール、デプロイします。こういった作業は、各ゲートウェイ毎に設定できるメンテナンスウィンドウの時間帯に行われます。
AWS Management Consoleは、AWS Storage Gatewayを完全にサポートしています。ボリュームの作成、スナップショットの作成やリストア、スナップショットの作成スケジュールの構成などをWebブラウザから行えます。スナップショットは、1、2、4、8、12、24時間間隔で設定できます。各ゲートウェイはAmazon CloudWatchのために監視用のメトリクスを提供します。
ユースケース
AWS Storage Gatewayには、以下のようなユースケースが考えられます
- バックアップ - ストレージのスペースを使いきるのを気にすることなく、ローカルデータをクラウドにバックアップできます。Amazon S3は容量無制限のストレージサービスです。バックアップのスケジュールも容易で、テープを別拠点に送付する必要もありません。また、セカンダリのデータセンタを事前に契約していおく必要もないので、いますぐにバックアップをはじめられます。
- ディザスタリカバリとBCP - クラウドを利用することで、ディザスタリカバリのためのハードウェア投資を削減できます。定常的かつ頻繁に、貴重なデータのスナップショットを暗号化して安全にクラウドに送ることができます。また、データだけでなく、システム自体のディザスタリカバリを考え、クラウド上にバックアップシステムを準備しておくことができます。その際に、既存のVMイメージをクラウドに持ち込むのにはVM Importのサービスを利用できます。
- データ移行 - データを既存データセンターからクラウドへ移行、もしくはその逆のケースも簡単に行えます。
セキュリティ
AWS Storage Gatewayは企業にとっても非常に使いやすいサービスであると考えています。 こちらは、良く聞かれるであろうセキュリティ上の考慮点です。
- AWSと各ゲートウェイの間のデータ転送は、SSLで暗号化されています
- クラウド側のデータAmazon S3に保存される)は、AES-256を用いて暗号化されます
- iSCSIのinitiatorは、CHAP (Challenge-Handshake Authentication protocol)を用いて、認証を行います
コスト
全てのAWSユーザーは、AWS Storage Gatewayの無料トライアルを利用することができます。各ゲートウェイ毎に、毎月$125の料金がかかります。スナップショットには、通常のEBSスナップショットの料金が適用されます。.データ転送料金は、AWSから出るデータ転送料が通常どおり必要となります（AWSに向かう転送量は通常通り無料です）。より詳細な料金情報は、Storage Gatewayのホームページでご参照ください。もし、無料使用枠の利用条件が適用されているなら、1GBまでのEBSスナップショットと、15GBのAWSから出るデータ転送料も、毎月無料となります。
今後の予定
AWS Storage Gatewayの今回のリリースでは、Gateway-Storedボリュームという形式のみサポートしています。今後、Gateway-Cachedボリュームという形式をサポートする予定です。Gateway-Storedボリュームは、オンプレミスのホストサーバーにアタッチされたローカルストレー ジ上に完全なコピーを保持します。そして同時に、そのバックアップ用のスナップショットをAmazon S3にアップロードします。これにより、データに対する高いアクセス性能を保ちつつ、耐久性の高いオフサイトのバックアップを可能にします。 Gateway-Cachedボリュームの場合は、ローカルストレージをよくアクセスされるデータのキャッシュとして利用します。データのコピー部分をク ラウドに保存します。こうすることで、ローカルストレージの負荷をAmazon S3に移す一方で、アクティブなデータに対する高いアクセス性能を保ちます。
また、アプリケーションレベルで利用できるスナップショットを作成をより簡単にするために、MicrosoftのVolume Shadow Copy Service (VSS)もサポートする予定です。
今回の発表はまさに、ハイブリッドクラウドのソリューションです。いつものように、このAWS Storage Gatewayをご利用頂いたユーザーの皆様からフィードバック頂けましたら、ロードマップにさらに機能を追加していきますので、是非フィードバックをお願い致します！
より詳細は、Storage Gatewayのホームページと、 Storage Gatewayユーザーガイド(英語)を参照ください。
玉川憲 (@KenTamagawa)
【AWS発表】 Virtual Private Cloudの中でRelational Database Serviceが利用可能に
今回の発表により、Amazon Relational Database Service (RDS) DBインスタンスを、 Virtual Private Cloud (VPC)の中で利用可能になりました。東京リージョンも含め、世界中の全公開リージョンで、VPCの中でRDSを活用できます。
今回の発表の背景
まずは簡単にRDSとVPCを復習しましょう。
RDSを用いると、リレーショナルデータベースの運用の手間を大幅に削減できます。ハードウェアの調達や設定、OSやデータベースのインストール、バックアップについて心配する必要が無くなります。さらに、冗長構成、障害時のフェールオーバーの設定、計算処理能力やストレージ容量の変更すら、簡単にできるようになります。RDSについては、日本語のセミナー資料、ハンズオン資料もご参照ください。
Virtual Private Cloudは、AWSクラウドの中に、プライベートで隔離された領域を作成します。VPCの中で、IPアドレスの範囲、サブネット、ルーティングテーブル、ネットワークゲートウェイ等の作成、編集を自由にできるので、まさに仮想ネットワーキングとも呼ぶべきサービスです。VPCに関しては、日本語のセミナー資料もご参照ください。
VPC内にRDSを作成するステップ
VPCの中にRDS DBインスタンスを起動するには、まずVPCを作成し、必要なサブネットを作成しIPアドレスの範囲を割り当てる必要があります。これらの設定は、上記の図にあるVPCのウィザードを利用しても設定できますし、コマンドラインツール、APIでも実施できます。
その後、DBサブネットグループ (DB Subnet Group)を作成します。DBインスタンスは、サブネットグループが指定しているサブネットの中のみで稼働させることができます。サブネットグループを作成する際に、利用しているリージョンの各アベイラビリティゾーン毎に少なくとも一つのサブネットを持っておいたほうが良いでしょう。RDSのマルチAZデプロイメントを利用する際に、スタンバイのDBを他のアベイラビリティゾーンで稼働させることが可能になります。たとえ、マルチAZを使わない場合でも、将来マルチAZを使うケースに備えて、各ゾーン毎に一つのサブネットを持っておきましょう。
次に、DBセキュリティグループを作成します(既存のものを使うことももちろん可能です)。DBセキュリティグループにより、DBインスタンスへのアクセスをコントロールできます。特定のEC2セキュリティグループ、もしくは、VPCセキュリティグループに属しているEC2インスタンスからのみアクセスを許可したり、特定のIPアドレスレンジからのみアクセスを許可できます。必要に応じて、VPCサブネットと関連するアクセスコントロールリスト(ACL)を用いることもできます。VPCの中ではより詳細なコントロールと柔軟性を持つことができるのです。
そして最後に、VPCの中でDBインスタンスを起動します。その手順の中で、DBサブネットグループとDBセキュリティグループを指定します。今回の発表では、MySQLのDBエンジンを用いることができます。今後、他のDBもサポートする予定です。DBインスタンスは、DBサブネットグループの範囲内のIPアドレスを利用する一つのElastic Network Interface(仮想ネットワークインタフェース)を持ちます。そのIPアドレスを使ってDBにアクセスすることも可能ですが、IPアドレスはマルチAZを用いた場合は変更し得るのでDBのDNS名を用いてアクセスすることを推奨します。
VPCへの移行
これまでRDS DBインスタンスを (VPCの外で)利用してきた方のVPCへの移行方法ですが、既存のDBインスタンスのスナップショットを取得し、スナップショットからDBインスタンスをVPCの中に作成することで、移行を行うことができます。注意点として、VPCの中で取得したスナップショットに対しては、VPCの外からアクセスできないことに気をつけてください。これは、セキュリティ上の理由で制限をかけています。
ユースケース
VPCの中でRDSが使えるようになったことにより、様々なユースケースが考えられます:
- VPC内のプライベートDBインスタンス - これはもっとも単純なユースケースで、インターネットの外からDBへのアクセスを全く考えていない場合に適しているでしょう。
- 外向けのWebアプリケーションが使うプライベートDB - Webアプリ用のサーバをパブリックサブネットに置き、DBインスタンスをインターネットアクセスを持たないプライベートサブネットに置きます。この場合、RDS DBインスタンスは、パブリックなIPアドレスを持たないことになります。
さあ使ってみましょう！
今回の発表により、東京リージョンで、VPC内のRDSも利用できるようになりました。VPC内ではEC2はもちろんのこと、ELBも利用可能になっていますので、多くのアプリケーションでVPCを活用できます。VPCの作成やサブネットの作成そのものは無料です。実際にVPC内にEC2やRDSのリソースを作成したときのみ通常の料金がかかります。是非、VPCを利用してみて、その柔軟性、利便性、コントロールの高さを感じてみてください！VPCに関する日本語詳細資料はこちら(AWSマイスターシリーズ日本語資料)からご利用ください。
玉川憲 (@KenTamagawa)
【AWS発表】 Amazon DynamoDB - インターネット時代のアプリケーションのために設計された高速でスケーラブルなNoSQLデータストレージ
本日の発表は、インターネット時代のスケーラブルなアプリケーションのために設計された高速かつスケーラブルなNoSQLデータベースである Amazon DynamoDBです。これは、Amazon Web Servicesが、Amazon S3やAmazon SimpleDBといった、ノンリレーショナルなデータベースとクラウドサービスの運用で培ってきた経験の集大成となる新サービスです。Amazon DynamoDBは信頼性、データ耐久性が高いデータベースサービスであり、そのデータ容量は無制限、アクセス性能を自在にコントロールできるという特徴を持っています。そして、そのデータは、SSD(Solid State Drive)に保存され、どのような規模であっても高速なパフォーマンスを提供できます。
下記の紹介ビデオをご覧ください(Youtube下部の『CC』から日本語キャプションを選択できます)。
インターネット時代におけるWebアプリケーションは、利用ユーザ数やトラフィック量、データ量が膨大に増えがちであり、しばしばデータベースをスケールさせるのに困難を伴います。Amazon DynamoDBを用いれば、開発者はアプリケーションに本当に必要な分だけのデータベースの性能でスモールスタートでき、そのアプリケーションが成長したときに、必要なだけ性能を増加させることができます。保存されているデータ量が増えるにつれて、テーブルも制限なしに自動的に大きくなります。そして、DynamoDBを使うユーザは、サーバや、ディスクや、ソフトウェアのインストール、設定、アップデート等を考えなくて良いのです。DynamoDBは、ユーザーが意識することなく、その裏側で自動的に十分な数のサーバにまたがってデータとトラフィックを分散させ、ユーザに指定された容量に見合うように調整します。DynamoDBは、どのようなスケールであっても、一般的に、平均数ミリ秒の安定した低遅延なパフォーマンスを発揮するのです！
では、もう少し詳細にDynamoDBをみてみましょう。
DynamoDBでは、スループット設定 (provisioned throughput) という仕組みを持っています。DynamoDBのテーブルを作成する際、どれくらいの読込みと書込みが必要か設定できます。AWSが裏側で、ミリ秒レベルの低遅延を維持しつつ、そのニーズにこたえられるように全てをセットアップします。もし後から設定を変更したければ、そのスループット設定を変更して、上げ下げすれば良いのです。AWSがそれにしたがって調整を行います。その設定は、オンラインでおこなえ、ダウンタイプや全体のスループットに影響はありません。言い換えれば、データベースがリクエストを処理している最中ですら、スケールアップすることが可能です。
DynamoDBにおいて、新しくテーブルを作成すると、約1～2分で利用可能になります。テーブルが作成されると、あとはデータをそこに(好きなだけ)保存するだけです。あとは、実際に使ったストレージ容量を支払うことになります。あらかじめストレージ容量を確保しておく必要無いのです。これも、ユーザーが意識することなく、裏側で、適切な量のストレージを調整しているのです。
ここまで読んでDynamoDB、良さそうだなと思っていただけたでしょうか？さて、では信頼性やデータ耐久性はどうでしょうか？一言でいうと、非常に高い信頼性、データ耐久性を持っています！DynamoDBのテーブルをあるリージョン(例えば、東京リージョン)で作成すると、そのデータは複数のゾーン(東京リージョンの中の異なる物理データセンタ)にまたがり同期的にコピーされます。こうすることで、サーバレベルの障害のみならず、万が一、データセンタレベルの障害の際にも影響をうけることがありません。
DynamoDBのパフォーマンスについては何度も強調しておきたいと思います。スモールスタートから(例えば、5リード/秒)、50リード、500リード、5000リード、さらに50000リード/秒にスケールアップすることができます。そしてこの変更の間もオンラインであり、アプリ側のコードに変更は必要ありません。もちろん、読込みだけでなく書込みに関しても同様のことが可能です。DynamoDBはシステムやビジネスとともに成長し、その成長の妨げになることは無いのです。
このDynamoDB、もちろん、AWS無料使用枠の中で利用できます。100MBのストレージ、5ライト(書込み)/秒、 10リード/秒(強一貫性 - strongly consistent reads - の場合) もしくは20リード/秒(結果整合性 - eventually consistent read - の場合)が無料になります。それを超えた場合は、料金はどれくらいのスループットでどれくらいのデータ量を保存したかで決まります。AWSの他のサービスと同様に、同一のリージョン内におけるEC2インスタンスとDynamoDBテーブルの間でのデータ転送には料金はかかりません。
初期設定では、256テーブルまで作成でき、10000リード/秒、 10,000/秒まで設定できるようになっています。より多くのテーブル数、読込み、書込みが必要な場合、こちらから申込みください。すでにご利用になられているお客様の中には、すでにこの初期設定を超えて利用されています。
AWS Management ConsoleからDynamoDBの利用
AWS Management Consoleに、新しくDynamoDB用のタブができています。新しいテーブルを作成し、スループットを設定し、インデックスを決め、CloudWatchアラームを作成するまで、Webコンソールから実施できます。
下記のフォームからキャパシティの設定を手動で設定します。
もしくは、簡単なカルキュレーターを用いて、必要なスループットを計算することもできます。
CloudWatchのアラームも下記から設定でき、たとえば、スループット設定のある一定の割合を超えたらメールで通知することも可能です。
さらにCloudWatchのメトリクスを使って、書込みや読込みのスループットを追加するタイミングを確認することもできます。
作成後に、あとから、スループットを変更するこもともちろん可能です。
DynamoDBを用いたプログラミング
さて、ここでは、より詳細に、DyanamoDBを使ったプログラミングについてみていきましょう。
まず、DynamoDBにおける各テーブルは主キー (primary key) を持ちます。今回のリリースでは、2種類の主キーがあり、シンプルハッシュキー(Simple Hash Keys)、レンジキーを持つコンポジットハッシュキー （Composite Hash Key with Range Keys）があります。
- シンプルハッシュキー (Simple Hash Keys) は、分散ハッシュテーブルであり、ユニークキーにおけるインデックスとして利用されます。キーは複数の処理、ストレージにハッシュされ、ワークロードを最適化します。
- コンポジットハッシュキー (Composite Hash Keys with Range Keys) では、、2つの属性を持つ主キー作成することができます。ハッシュ属性と、レンジ属性です。キーの種類でクエリーをかけると、ハッシュ属性は完全に一致する必要がありますが、レンジ属性の場合、範囲で特定することができます。例えば、"all orders from Ken in the last 24 hours"といったクエリーをかけることができます。
DynamoDBにおける各アイテムが、キー・バリュー・ペアで構成されています。各バリューは、ストリング、数値、ストリングセット、数値セット のどれでも構いません。アイテムを取得する際は、強一貫性(strongly consistent read)か、結果整合性(eventually consistent read)のどちらかをニーズにあわせて選択します。結果整合性の場合は、半分のリソースしか消費しません。そのため、スループットにおけるトレードオフを考慮してどちらか選択する必要があります。
AWS SDKsもDynamoDBのためにアップデートされています。下記の例は、AWS SDK for PHPを用いたものです。最初はSDKを読み込み、オブジェクトへのリファレンスを作成します。
テーブルの作成には、テーブル名、キーの設定、スループット設定の３つの引数が必要です。
// Create a table
$Schema = array('HashKeyElement' =>
array('AttributeName' => 'RecordId',
'AttributeType' => AmazonDynamoDB::TYPE_STRING));
$Throughput = array('ReadsPerSecond' => 5, 'WritesPerSecond' => 5);
$Res = $DDB->create_table(array('TableName' => 'Sample',
'KeySchema' => $Schema,
'ProvisionedThroughput' => $Throughput));
$Schema = array('HashKeyElement' =>
array('AttributeName' => 'RecordId',
'AttributeType' => AmazonDynamoDB::TYPE_STRING));
$Throughput = array('ReadsPerSecond' => 5, 'WritesPerSecond' => 5);
$Res = $DDB->create_table(array('TableName' => 'Sample',
'KeySchema' => $Schema,
'ProvisionedThroughput' => $Throughput));
create_tableの返り値が戻ると、テーブルのステータスは, CREATINGとなります。テーブルが作成されるとACTIVEに変わり、データを保存することができます。describe_table functionを用いてステータス等の情報の取得ができます。
こちらがそのPHPオブジェクトの結果です。
CFSimpleXML Object
(
[CreationDateTime] => 1324673829.32
[ItemCount] => 0
[KeySchema] => CFSimpleXML Object
(
[HashKeyElement] => CFSimpleXML Object
(
[AttributeName] => RecordId
[AttributeType] => S
)
)
[ProvisionedThroughput] => CFSimpleXML Object
(
[ReadsPerSecond] => 5
[WritesPerSecond] => 5
)
[TableName] => Sample
[TableSizeBytes] => 0
[TableStatus] => ACTIVE
)
(
[CreationDateTime] => 1324673829.32
[ItemCount] => 0
[KeySchema] => CFSimpleXML Object
(
[HashKeyElement] => CFSimpleXML Object
(
[AttributeName] => RecordId
[AttributeType] => S
)
)
[ProvisionedThroughput] => CFSimpleXML Object
(
[ReadsPerSecond] => 5
[WritesPerSecond] => 5
)
[TableName] => Sample
[TableSizeBytes] => 0
[TableStatus] => ACTIVE
)
新しいアイテムを挿入するのは簡単です。各アイテムのデータタイプを指定する必要があります。下記がその例です。Squareには、二乗した数字を入れています。(他にも、データタイプとしては、TYPE_ARRAY_OF_STRINGS、TYPE_ARRAY_OF_NUMBERSが使えます)
for ($i = 1; $i < 100; $i++)
{
print($i);
$Item = array('RecordId' => array(AmazonDynamoDB::TYPE_STRING => (string) $i),
'Square' => array(AmazonDynamoDB::TYPE_NUMBER => (string) ($i * $i)));
$Res = $DDB->put_item(array('TableName' => 'Sample', 'Item' => $Item));
}
{
print($i);
$Item = array('RecordId' => array(AmazonDynamoDB::TYPE_STRING => (string) $i),
'Square' => array(AmazonDynamoDB::TYPE_NUMBER => (string) ($i * $i)));
$Res = $DDB->put_item(array('TableName' => 'Sample', 'Item' => $Item));
}
RecordIdのキーでデータを取得するのも簡単です。
for ($i = 1; $i < 100; $i++)
{
$Key = array('HashKeyElement' => array(AmazonDynamoDB::TYPE_STRING => (string) $i));
$Item = $DDB->get_item(array('TableName' => TABLE,
'Key' => $Key));
print_r($Item->body->Item);
}
{
$Key = array('HashKeyElement' => array(AmazonDynamoDB::TYPE_STRING => (string) $i));
$Item = $DDB->get_item(array('TableName' => TABLE,
'Key' => $Key));
print_r($Item->body->Item);
}
PHPオブジェクトとして戻る各アイテムはこのようになります。
CFSimpleXML Object
(
[RecordId] => CFSimpleXML Object
(
[S] => 44
)
[Square] => CFSimpleXML Object
(
[N] => 1936
)
)
(
[RecordId] => CFSimpleXML Object
(
[S] => 44
)
[Square] => CFSimpleXML Object
(
[N] => 1936
)
)
DynamoDBのAPIは、queryやscan関数も含んでいます。query関数は、主キーの属性値をクエリーし、比較演算を利用できます。scan関数は、テーブル全体を検索し、フィルタリングをかけます。一般的にクエリーのほうがスキャンよりも効率的です。
また、アイテムの更新、複数アイテムの取得、アイテムの削除、複数アイテムの削除も行えます。条件付き更新も使えますが、詳しくは、Amazon DynamoDB Developer Guideを参照ください。
いかがでしょうか？このDynamoDBは米国東リージョンで利用できますが、東京リージョンではまだ利用できません。しかしながら、ぜひ日本からもDynamoDBを使ってみて、フィードバックを頂ければと思います！
玉川憲 (@KenTamagawa)
【AWS発表】 AWS無料使用枠で、 EC2のMicrosoft Windowsサーバも利用可能に
AWS無料使用枠は、AWSアカウントを作成したユーザーが1年間の間、AWSリソースのある一定の使用枠を無料で利用できるプログラムです。これまで、EC2インスタンスのうち、Linuxのマイクロインスタンス(t1.micro)が毎月750時間無料で使えるようになっていましたが、今回の発表により、さらに、Microsoft Windows Server 2008 R2もマイクロインスタンスで毎月750時間無料で使えるようになりました！
新規にアカウントを開設したユーザのみならず、すでに無料使用枠を使っていたユーザも含め、すべてのAWSリージョン(GovCloudは除く)でこのWindowsの無料が適用されます。
マイクロインスタンスは、それほど定常的な処理能力は高くないもの瞬発的なバースト処理ができるインスタンスタイプであり、EC2を試用してみたり、開発、テスト環境、AWSアプリケーションの構築、Webサイトのホスティングなどに用いることができます。
下記のように、AWS Management Consoleを用いて、Windowsのインスタンスを立ち上げることができます。
下記のガイドが参考になります。
- はじめてのアマゾンクラウド (EC2でWindowsを立ち上げリモート接続)
(このガイドを利用する際は、Windows Server 2008 R2を選択することにご注意ください) - EC2 Microsoft Windows Guide (英語)
- Getting Started Guide: Web Application Hosting for Microsoft Windows (英語)
- Windows and .NET Developer Center (英語)
- AWS Microsite(英語)
AWS無料使用枠では、Windows Server 2008 R2を毎月750時間利用できるだけでなく、さらに、それとは別にLinux (マイクロインスタンス)も毎月750時間利用できます。ロードバランサ(Elastic Load Balancer）や、外付け仮想ディスク(Elastic Block Storage)、S3ストレージ、SimpleDBストレージ、キューイングサービス(Simple Queue Service)、通知サービス(Simple Notification Service)、監視サービス(CloudWatch）も無料枠を用意しております。また、今回の発表に伴い、EBSストレージのスペースも30GBに拡張し、I/Oリクエストも200万に拡げています。ぜひAWSを利用する際にご活用ください！
玉川憲 (@KenTamagawa)
【AWS発表】 クラウドに専用線接続できるAWS Direct Connectが東京リージョンでも利用可能に
AWS Direct Connectを用いると、お客様のオフィス、データセンター、コロケーション施設から、専用線経由でAWSクラウドを利用することができます。
AWS Direct Connectを利用することで、インターネット経由でAWSクラウドを利用するのに比べると、ネットワークコストを削減し、安定した広い帯域を利用できます。このAWS Direct Connectは、今年8月時点ですでに米国東リージョンで利用可能になっており、 さらにその後、米国西リージョンでも利用可能となっていました。今回の発表は、とうとうこのAWS Direct Connectが東京リージョンをはじめ、4リージョンでも利用可能になったというものです！
- 東京リージョン - Asia Pacific (Tokyo): Equinix Tokyo (新)
- US West (Northern California): Equinix San Jose, Coresite One Wilshire Los Angeles (新)
- EU West (Ireland): Telecity Sovereign House, London (新)
- Asia Pacific (Singapore): Equinix Singapore (新)
- US East (Northern Virginia): Equinix Northern Virginia
AWS Direct Connectのユースケースは以下のように、多岐にわたります。
- AWSクラウドとオンプレミス環境間で大規模データのやりとりがある
- AWSクラウドとオンプレミス環境間でネットワークパフォーマンスが重要
- オンプレミス環境のSANやNASなど、顧客企業の既存投資を生かしつつ、AWSクラウドを使った拡張をする
- AWSクラウドをハブとして、企業間で音楽やビデオの大規模データをやりとりする
AWS Direct Connectの接続ロケーションと、オンプレミス環境（データセンター、オフィス、コロケーションなど）との間にネットワーク回路網を構築し、お客様にAWS Direct Connect をご利用いただけるよう支援する「AWS Direct Connect ソリューションプロバイダー」も増え続けています。現在、日本においては、NTTコミュニケーションズ株式会社、KVH株式会社、ソフトバンクテレコム株式会社、株式会社野村総合研究所が、AWS Direct Connectソリューションプロバイダーとなっています。
AWS Direct Connectでも、他のAWSクラウドと同様、従量課金で用いることができます。使用したネットワークポートの数、AWSのクラウドサービスから外部へ 向かうデータ転送量によって課金されます。外部からAWSクラウドへのデータのアップロードは無料です。東京リージョンのポートの料金に関しては、1 Gbps ポートは$0.30/時間 、10 Gbps ポートは$2.25/時間となります。東京リージョンのデータ転送量（アウト）は、$0.045/GBです。料金の詳細はこちらをご覧ください。
AWS Direct Connectを利用するには、下記のフォームを申請していただければ可能です。
専用線接続してAWSクラウドを用いることができるようになり、日本においても企業ユースにおけるクラウド利用の敷居を下げ、さらにクラウドの利用が高まるに違いありません。皆様にAWSをお使い頂けるように、今後も、ご要望に続々とお応えしていきますので、AWSの今後の動向にもぜひご注目ください！
玉川憲 (@KenTamagawa)
【AWS新発表】 AWS Management Console上で各EC2インスタンス、EBSボリュームから直接アラームを作成できるように
今回の発表により、監視サービスであるAmazon CloudWatchのアラームを、AWS Management Consoleを用いて(Webコンソール)、個別のEC2インスタンスやEBSボリュームから直接簡単に作れるようになりました！
下記に一通り、今回の新機能をWebコンソール上で見ていきましょう。
EC2の各インスタンス、EBSボリュームからアラーム作成
Management Console上で、EC2インスタンスやEBSボリュームから直接アラームを作成できるようになりました。
例えば、あるサーバのインスタンスにおいて、EC2から出ていくネットワーク流量(Network Out)が5分間で1.5Mバイト超えた際にアラームを上げたい場合があるとします。その際は、EC2インスタンスのタブの中から"Create Alarm"ボタンを押すことで、アラームを作成できます。
下記のように、所望の期間とメトリクスを選択することができます。また、通知サービスSNSの既存トピック(配信先メールアドレスが入っているもの)を選択して通知を行うこともできますし、下図のように、このアラーム作成時に、新たに通知用のトピックとして、配信するメールアドレスを登録することもできます。
スレッショルドとなる値はグラフの中で赤で表示されます。
アラームを作成すると、Monitoringタブの中で、このインスタンス用の数が表示されるようになります。
そちらをクリックすると、より詳細を見ることができます。
ネットワークの流量や、CPUの使用量、ディスクへの書き込み量など、様々なメトリクスを用いてアラームが作成できますね！ぜひ、皆様もアラームを作成してみてください！
玉川憲 (@KenTamagawa)
【AWS発表】 Virtual Private Cloudの中でネットワークインタフェースを自在にコントロールできるElastic Network Interfaceの発表
AWSが提供しているサービスを見て頂くと、これまではコントロールできない一枚岩なものだと思われていたアーキテクチャ・コンポーネントを、個別にコントロールできる要素毎に分けていき、クラウドサービスとしてサービス化してきたことが分かると思います。
例えば、EC2インスタンスを作成したのちに、個別にEBSボリュームを必要に応じて作成して付与することができます。固定的な量のストレージを持っていた既存の物理サーバーの調達と比べると、ずっとダイナミックで柔軟です。
本日、Virtual Private Cloudの中で稼働するEC2に関して、柔軟にコントロールできるさらなるコンポーネントを発表します。まず、EC2インスタンスから、IPアドレス(とそれに関係する沢山の要素)を切り離し、それをElastic Network Interface (ENI)としてサービス化しました。エラスティックなネットワークインタフェースの誕生です！さらに、そのENIは、各インスタンスに対して、二つまで付与することができるようにしました！
各ENIは、VPCの中の一つのサブネット(つまり特定のアベイラビリティゾーン)に所属します。各ENIが、下記のような属性を持ちます。
- 詳細
- プライベートIPアドレス
- Elastic IPアドレス(固定IPアドレス)
- MAC アドレス
- セキュリティグループ(複数可能)
- ソース/デスティネーション・チェックフラグ (Source/Destination Check Flag)
- 終了時消去フラグ (Delete on Termination Flag)
この新モデルにおいて重要なのは、このENIがあると、VPCの中でEC2を立ち上げる際に特定のVPCサブネットの中に置く、ということ自体はこれまでと比べるとあまり意味が無くなったということです。各ENIはそれぞれ特定のサブネットに属しています。各EC2インスタンスに、二つのENIを付加することができるので、異なるサブネットに属するENIを付加することもできます。
EBSボリュームと同じように、ENIはEC2インスタンスを起動しようが終了しようが、それとは異なるライフタイムを持つことができます。ENIの調達は柔軟で(Elastic!)、必要なときにすぐに調達し、不必要であれば捨てることができます。また、ENIを前もって作成しておいて、それをEC2インスタンスを起動した際に、付加することができる点も重要でしょう。もちろん、稼働中のEC2インスタンスにENIを付加することもできます(ホットアタッチと呼びましょう)。終了時消去フラグがセットされていない限り、EC2インスタンスを終了してもENIは存続しつづけます。EC2作成時には、特に指定しない限り、ENIが自動的に作成されます。そして、デフォルトで終了時消去フラグが設定されているので、EC2終了時にはENIも消去されます。ですので、特にENIを使用しないときは、これまで通り、それを意識せずに使うことができるでしょう。
今回の新しいレベルのアドレス周り、セキュリティ周りの柔軟性を手にすることで、様々な利用方法がでてきます。こちらがその一例です。
管理用のネットワーク (バックネット) - Webサーバーやデータベースサーバーに外向けと内向け用にENIの2枚ざしが可能になります。インスタンスの最初のENIはパブリックサブネットに所属させ、0.0.0.0/0 (全トラフィック)を、VPCのVPCのインターネットゲートウェイにルーティングします。インスタンスの2番目のENIは、プライベートサブネットに所属させ、0.0.0.0/0 (全トラフィック) を、社内イントラネットなどにつながるVPNゲートウェイにルーティングします。そして、SSHアクセス、管理/ログ用途に、プライベートネットワークを使用します。異なるセキュリティグループを各ENIに適用することが可能なので、最初のENIに関してはポート80のトラフィックを許可し、2番目のENIにはポート22へのトラフィックを許可する設定にします。
MACアドレスベースのライセンス対応 - 商用のソフトウェアの中には、特定のMACアドレスに紐づけてライセンシングを行っている場合があります。そのような場合、ENIのMACアドレスに対してライセンスを発行することが可能です。もし、インスタンスを変更する場合や、インスタンスタイプを変更する場合(スペックを変えたいとき)でも、このENIを新しいインスタンスに付与することが可能です。
Multi-VIF アプリケーション - EC2インスタンスの上で、ロードバランサ、プロキシサーバ、NATサーバを運用した際に、あるサブネットから他のサブネットにトラフィックをパスすることが可能です。この場合、ソース/デスティネーション・チェックフラグをオフにすることで、インスタンスに自分自身にアドレスされていないトラフィックをも処理することを許可できます。ネットワーク製品やセキュリティ製品を持っているベンダーが、この複数ENIを利用することでAMIの作成を開始頂けることを期待しています！
低予算での高可用性実現 - ENIをインスタンスに付加しておき、もしインスタンスに障害があると、他のインスタンスを起動しENIをそちらに付与します。数秒でトラフィックの処理を復帰することが可能です。
こちらは、ENIを用いた際の、VPC、サブネット、ルーティングテーブル、VIFの関係を示した図です。
注意して頂きたいのは、インスタンスに二つのパブリックENIを付与することは、EC2インスタンスに二つのパブリックなIPアドレスを付与することとは、同じでは無い、ということです。ルーティングにスペシャルな設定をしない限り、あるパケットが特定のENIを通して届くことを確かめる術がありません。沢山のユーザーが、各EC2インスタンスに対して複数のIPアドレスを持たせたいという要望をお持ちであることは我々も認識しておりますので、2012年にそちらをサポートすることを計画しております。
追記： ENIそのものの作成した際の料金は、セキュリティグループやルーティングテーブルと同様にかかりません。ただし、EIP(固定IPアドレス)をENIに割りあて、そのENIがEC2インスタンスで使用されていない場合は、EIPの料金がかかります。
AWS Management Consoleもすでに、ENIをサポートしています。
"Create Network Interface” ボタンを押すことで、新しいENIを作成できます。
VPCの中でEC2インスタンスを起動する際に、追加のENIを特定することが可能です。
もちろん、下記のようにENIを既存のインスタンスに付加できます。
さて、今回の新発表いかがでしょうか？ぜひ、使ってみてフィードバック頂けると有難いです！
玉川憲 (@KenTamagawa)
【AWS発表】 南米 (サンパウロ) リージョンの発表
まだUS West (Oregon) Regionを発表したばかりですが、今回はさらに新しいリージョンの発表です。とうとう南半球のブラジルはサンパウロに、リージョンを開設しました。どこからか、アマゾンがアマゾンに進出、という声が聞こえてきそうです(笑)。このリージョンの発表によって、南アメリカ、中央アメリカのユーザーも、EC2、S3などをはじめとするAWSのサービスを高速なネットワーク速度で利用できるようになりました。
新リージョン
南米 (サンパウロ) - South America (Sao Paulo) リージョンでは下記のサービスをご利用頂けます。
- Amazon Elastic Compute Cloud (EC2) と関連サービス
(Elastic Block Store、 Virtual Private Cloud、 Elastic Load Balancing、 Auto Scaling) - Amazon Simple Storage Service (S3)
- Amazon SimpleDB
- Amazon Relational Database Service (RDS)
- Amazon Simple Queue Service (SQS)
- Amazon Simple Notification Service (SNS)
- Amazon Elastic MapReduce
- AWS CloudFormation
- Amazon CloudWatch
- VM Import
これまでもすでに、Route 53とCloudFrontのエッジロケーションはサンパウロに存在していました。
AWS Toolkit for Visual Studioもすでに、ドロップダウンメニューの中に新リージョンを含んでいます。メニューをリフレッシュするために再起動が必要なことにご注意ください。
これは、世界で8番目のAWSのリージョンになり、南アメリカでは初のリージョンです ( AWS Global Infrastructure Mapで詳細な情報をみることができます)。じつは、2011年は、4つのリージョンを開設したため、リージョン数は2倍になりました。AWS Management Consoleから、Regionを見ると下記のように8つから選べるようになっています。日本からでも、ブラジルにサーバーを立てるのは非常に簡単です。下記の中から、サンパウロを選択して、EC2インスタンスを起動するだけです！
ポルトガル語対応
AWSのWebサイトの一部も、ポルトガル語に対応しました。右上のメニューから、ポルトガル語に変更可能です。
ブラジルにもAWSチームがあり、すでに営業、マーケティング、エバンジェリストがいます。我々のブラジルのエバンジェリストは、Jose Papoで、サンパウロに在住しています。彼は、ポルトガル語とスペイン語で、AWSブログを開始する予定です (ポルトガル語、スペイン語)。
お客様
すでにブラジルにも沢山のお客様がいらっしゃいますが、下記はその一部です。
- Peixe Urbanoは、ブラジルのディスカウントクーポンのリーダーです。AWS上にシステムを構築し、トップ50のサイトを固定資産無しで運用しています
- Gol Airlines (ブラジルで最大の航空会社)はAWSを用いて顧客に無線サービスを提供しています
- R7は、ブラジルで最も著名なニュースポータルの一つです。このサイトは、S3、CloudFrontとともに、EC2の自動スケールアウトを利用しています
- Oramaは、全ブラジル国民により簡単な投資をミッションとした金融機関です。顧客管理システムの大半をAWS上で構築しています
- Itaú Culturalは、非営利の文化団体です。こちらのIT部門は、AWS上で新しいプロジェクトを構築中です
- Casa & Videoは、ブラジルで最も大きな家電販売会社です。こちらは、AWSに移行し、トラフィックのピークに対応しています
ソリューションプロバイダー
ブラジルにおける、ISVとシステムインテグレーターのパートナーエコシステムはすでに、AccentureやDeloitteといったグローバルカンパニーとともに、Dedalus、CI&T、Inforといったローカルなベンダーも含んでいます。
私も早速、日本から一番遠い、このブラジルのリージョンにサーバーを立ててみました。日本にいながら、ものの数秒でサーバーがすぐ起動しました(おそらく日本人で初めてのサーバーとなったことでしょう)。皆様もぜひ、サーバーを起動してみてください！
玉川憲 (@KenTamagawa)
【AWS発表】 Amazon Simple Email Service (SES)がSMTPをサポート
今回の発表により、Amazon Simple Email Service (SES)が、SMTPをサポートしました。より簡単に大量のメール発信を行うことができるようになりました。この機能についてはたくさんのご要望を頂いておりましたので、この早いタイミングで発表できるのを嬉しく思っております！
SMTPの設定は、AWS Management ConsoleのSESタブを用いて、Webコンソール上からおこなえるようになっています。
次のページに、SESでSMTPを利用するステップが書いてあります。
基本的に、SESを利用する際に、コードを書く必要がなくなりました。まず、AWS Management ConsoleのSESタブを用いてAWS Management ConsoleのSESタブを用いて、Webコンソール上からSMTPに用いるユーザーを入力します。そうしますと、下記のように、SMTPクライアントに設定するそのユーザー名とパスワードを得ることができるので、それを用いてemailクライアントの設定が行えます。
上記のプロセスの中で、適切な権限とポリシーを所有したIAMユーザーが自動的に作成されます。そして、作成されたSMTP用のユーザー名とパスワードを用いて、 メールクライアントを設定し(Thunderbird, Outlook, and so forth)、メールの配信にSMTPを用いることができるのです。
もちろん、配信を行う際にはこれまでどおり、利用する配信元("from")のアドレスを認証しておく必要があります。また、SESは利用開始直後はサンドボックスモード（テストモード）に設定されているので、本番環境への申請をあげて通しておく必要があります。これらの作業も、Webコンソールの上から行うことができます。
より詳細に関しては、 SES Developer Guide (英語) のSMTPをご参照ください。こちらでは、SMTPクライントの設定だけでなく、ソフトウェアパッケージ(Jiraなどのツール)にSESを統合する例、アプリケーションコードからSMTPで送信する例 (PHP + MySQLの例)を含んでいます。さらに、Sendmail、Postfix、EximといったサーバーサイドのMail transfer agents (MTAs)にSESを統合する方法も解説しています。
SESを用いて、大量のメール配信を、簡単により安価に行ってみてください！
玉川憲 (@KenTamagawa)
【AWS発表】 リザーブドインスタンスに新しい2つの料金モデルを追加
皆様、EC2のリザーブドインスタンスという料金モデルはご存じでしょうか？通常の時間課金のモデルは、オンデマンドインスタンスと呼ばれますが、リザーブドインスタンスは、あらかじめ予約金を払うことにより、時間課金が通常よりもさらに安くなるという形式のEC2料金モデルであり、50%のコスト削減を可能にします。リザーブドインスタンスには、1年と3年の形式があり、用途に応じて使い分けて頂けます。
このリザーブドインスタンスは非常に広く使われておりますが、今回の発表は、このリザーブドインスタンスに新しい２つの形式を追加したというものです。ライトユース・リザーブドインタンス (Light Utilization)、ヘビーユース・リザーブドインタンス (Heavy Utilization) です。これまでのリザーブドインスタンスも、もちろん用いることができ、こちらはミディアムユース・リザーブドインスタンス(Medium Utilization)と呼ばれます。
もしサーバーを常に利用しており、それが79%以上の利用率であるなら、ヘビーユース・リザーブドインタンスを用いるとよいでしょう。こちらは、最初に予約金を支払うことで、時間課金が非常に低額になるため、結果的には、通常のオンデマンドインスタンスと比べて、最大58%のコスト削減につながります。
追記：こちらの場合は、サーバーを利用を使う使わないに限らず、契約期間の間、時間課金が発生します。つまり、購入時点で、予約金と時間課金x契約期間で、利用料金が確定されます。
逆に、常にサーバーを使っているわけではなく、数週間のうちの数時間、もしくは、数日しか使わないのであれば、ライトユース・リザーブドインタンスがむいているでしょう。例えば、ディザスタリカバリのためにAWSを用いるには、最適でしょう。リザーブドインスタンスにはキャパシティ保障の仕組みがあるため、必要なときに必ずEC2インスタンスを立ち上げることができます。ライトユース・リザーブドインタンスの場合は、もっとも低額の予約金を支払い、他と比べると割高の時間課金を支払うことになりますが、最大で33%のコスト削減につながります。
どの料金モデルが最適か決定するひとつの方法として、もっとも低額な料金を実現できるものを選ぶことが挙げられます。下記の損益分岐点の図を見て頂くと、それぞれの利用率において、下記の料金モデルが適していることがわかります。
15%以下: オンデマンドインスタンス
15% - 40%: ライトユース・リザーブドインタンス
40%-80%: ミディアムユース・リザーブドインタンス
80%以上: ヘビーユース・リザーブドインタンス
異なる選択方法として、予約金の量を考慮する方法もあります。例えば、3年のm1.xlargeのリザーブドインスタンスを評価する場合は、下記のような料金表となります。つまり、ライトユースの場合は、最大33%のコスト削減になり、予約金は$1200です。非常に低額のコミットメントで、ディスカウントを得ることができます。
さて、ここで、これらのモデルを組み合わせて利用する具体例をとりあげて考えてみましょう。Webサイトを稼働すると想定し、EC2インスタンスが最低2台必要であると仮定します。営業日にはよりトラフィックがあるので追加1 - 2台、さらに、ピーク時は3台追加で必要であるとします。また、1日に一度はバッチのために2 - 3時間は1インスタンス必要となります。そうすると、下記のような組み合わせを利用することができます。
- 2つのヘビーユース - 通常の負荷を対処
- 2つのミディアムユース - 営業費のためのスケールアップ
- 3つのオンデマンドインスタンス - ピーク時用のスケールアップ
- 1つのライトユース - バッチ処理の対応
グラフ化すると下記のようになります。
AWS Management Consoleも今回の発表にあわせて機能追加されましたので、複数のリザーブドインスタンスをショッピングカートのように購入できるようになっています。ちなみに、予約金は購入したその場で請求されますが、ヘビーユース、ライトユースなどの利用料金のうち時間課金分は、通常の月毎の請求に含まれることになります。
AWSは運用を改善することでコスト削減し、それをお客様に還元して低料金でお使い頂けますように継続的に努力をしています。今回の新しいリザーブドインスンタスもそうした活動の一環であり、皆様に気に入って頂けますと幸いでございます。是非、新しいリザーブドインスタンスもご利用ください！
玉川憲 (@KenTamagawa)
【AWS発表】 アーキテクチャのダイアグラムのためのAWSシンプルアイコンの発表
オンデマンドに調達できるインフラストラクチャの恩恵を最大限に得るためにも、アーキテクチャを吟味することは必須の事柄になってきました。クラウドコンピューティングにより、これまで以上にアプリケーションのアーキテクチャが重要になっているといえるでしょう。
アーキテクチャのダイアグラムも、アーキテクチャや開発者にとっては非常に価値あるものです。アプリケーションとそのアーキテクチャについて素早くコミュニケーションを図る際に、図示かすることで、曖昧さを減らし、より明確にわかりやすくできます。AWSとしても、AWSを最大限に利用したアーキテクチャを皆様とシェアして、フィードバックをして頂くことを大切にしています。
そのため、今回の発表では、AWSのサービスや機能に関する、AWSシンプルアイコンセットをリリースしました。このアイコンセットは、Architecture Centerから、ダウンロードできます。お客様やパートナー様は、こちらを用いて、見栄えが一貫したダイアグラムを作成することができ、そのダイアグラムを世界中とシェアすることができます。今回のアイコンセットには、数種類のアーキテクチャダイアグラムが例として含まれており、ダイアグラムの中でのアイコンの使い方にもガイドラインを用意しています。これらのアイコンを用いて、皆様のホワイトペーパー、プレゼンテーションやその他の用途にご自由にお使い頂けます。
複数のフォーマット(PPTX、VISIO Stencil、SVG、EPS、オンラインツールであるCacoo)をサポートしていますので、好きなものを使ってダイアグラムを書いて頂けます。
今回の発表は、このアイコンセットの最初のリリースです。今後も、このアイコンセットを我々の最新サービスやツールにに適合するようにアップデートしています。是非利用してみて、フィードバックください！
玉川憲 (@KenTamagawa)
【AWS発表】 Amazon ElastiCacheが東京リージョンを含め4つのリージョンで利用可能に。CloudFormationのサポートも開始
皆様、とうとうAmazon ElastiCacheが東京リージョンにもやってきました！東京リージョンを含め、4つのリージョンで使えるようになりました。また、AWS CloudFormationによるサポートも開始しました。
東京リージョン含め4つのリージョンで利用可能に
今年の8月にAmazon ElastiCacheが米国東リージョンで利用可能になりました(ElastiCacheのブログ記事)。それ以来多くの日本の皆様に、東京リージョンで使えるようになるのを待って頂いていたのではないでしょうか？
今回の発表により、東京リージョン - Asia Pacific (Tokyo)- 、US West (N. California)、EU West (Dublin)、Asia Pacific (Singapore)、で利用可能になりました。これらのリージョンで、インメモリのキャッシュサービスを数分でご利用になれるのです！
最新のリージョンとエッジロケーション(CloudFrontとRoute 53用)は、AWS Global Infrastructure mapから参照になれます。
マウスを地図の上に持っていくと、下記のような情報が表示されます。
CloudFormationのサポート
ElastiCachのキャッシュクラスターを、AWS CloudFormationテンプレートを用いてデプロイや編集が可能になりました(CloudFormationについてはこちらのブログ記事を参照ください)。テンプレートにより、キャッシュクラスタ、キャッシュパラメータグループ、キャッシュセキュリティグループを特定できます。
ElastiCacheのCloudFormationテンプレートのサンプル(上記のもの)を用意しています。こちらのテンプレートでは下記のリソースを作成しています。
- Amazon EC2インスタンス
- ポート22 (SSH)と80 (HTTP)を空けたEC2セキュリティグループ
- 特定のノード数を持ったElastiCache キャッシュクラスタ
- EC2からのみのアクセスを許したキャッシュセキュリティグループ
- CloudFormationの2つの関数と、ElastiCacheの1つの関数のみ呼ぶことが許されたIAMユーザー
ご要望がございましたら、無料WebセミナーのシリーズであるAWSマイスターシリーズでElastiCacheもとりあげたいと思いますので、どしどしお寄せくださいませ！
玉川憲 (@KenTamagawa)
【AWS発表】 Virtual Private Cloudの中でロードバランサ(Elastic Load Balancing)が利用可能に
皆様にもよくお使い頂いているロードバランサのクラウドサービス、 Elastic Load Balancing (ELB)が、Virtual Private Cloud (VPC).の中でもご利用頂けるようになりました！ELBが持つSSL termination、ヘルスチェック、スティッキーセッション、CloudWatchの監視等もAWS Management ConsoleのWebコンソールから設定できます。もちろん、ELBのAPIや、コマンドラインツールをもちいることも可能です。
VPC内でELBを用いる際には、セキュリティグループ(ファイヤウォールの設定)をELBに割り当てます。そして、ELBをVPC内のサブネットに配置します。サブネットのアクセスコントロールリスト(Access Control List)も利用可能です。ELBの配下におくEC2インスタンスはパブリックIPアドレスを持つ必要はありません。VPCが提供するサブネット、セキュリティグループ、ACLを利用することで、ELBやその配下のEC2インスタンスに対する詳細な管理ができることがお分かりでしょう。
下記は今回の発表のアーキテクチャ図です。
詳細な点にはなりますが、、VPCの中にELBを作成する際には、少なくとも一つのサブネットを設定する必要があります。ELBは各アベイラビリティゾーンにおいて、一つのサブネットの中で稼働します。推奨設定としては、各ELBごとに、サブネットを設定することです。ELBがスケーリングする仮定においても、各ELBに十分なIPアドレスが割り当てられるように、サブネットは少なくとも100個のIPアドレスを含めるようにしておきましょう(/25よりも大きく)。
VPC自体の設定は無料かつ、今すぐにも利用できますので、皆様にもすぐに今回のELBをVPCの中で使って頂けます。是非使ってみてください！
また、AWSのいつものアプローチの通り、ELBにおけるIPv6などその他の機能も、VPCの中で使えるようにしていきます。追加の拡張機能も継続して開発していきます！
玉川憲 (@KenTamagawa)
【AWS発表】 EC2インスタンスのステータスモニタリング
AWSのリソースの状況に関して、より分かりやすく情報を提供できるように、幾つかの新機能の開発に取り組んでいます。まず、本日の発表は、AWSが予定している運用作業のなかで、ユーザーが所有しているEC2インスタンスに影響がある際に、そちらをそのユーザーのWebコンソール上で分かりやすく表示する機能です。
現在、EC2インスタンスに影響がある運用管理系のイベントとしては3種類のものがあります。システムリブート(System Reboot)、インスタンスリブート(Instance Reboot)と、リタイヤ(Retirement)です。こういったイベントが行われる際には、これまではemail経由のみで通知されていました。今回の発表により、この情報をAPI経由、もしくは、AWS Management Console経由で利用できるようにすることで、ユーザーがこのようなイベントに対して手作業、もしくはプログラムによって対処できるようにしています。
システムリブート - EC2インスタンスが稼働している「ハードウェアかソフトウェア」にメンテナンス作業が必要な場合には、システムリブートをスケジュールします。ほとんどのアップグレードや改修はリブートをしなくても実行することができるのですが、一部のものに関してはリブートする必要がでてきます。これは滅多に行われないのですが、どうしても必要なときのみシステムリブートを行うということです。このシステムリブートが行われるとき、影響をうけるユーザーは事前にその日時を知らされることになります。その日時がきたとき、そのインスタンスも含めてリブートされます。リブート自体は2分~10分で終了するとおもいますが、これはシステムリブートの中身やインスタンスの設定にもよるでしょう。もし、皆様のインスタンスでシステムリブートがスケジュールされた場合、事前に他のインスタンスに切り替えておいたり(EBS-backedのインスタンスの場合、stopしてstartすると他のハードウェア上でインスタンスが立ち上がります)、もしくは、システムリブートされた後の状態のチェックを考慮していただくことになります。
インスタンスリブート - インスタンスリブートはシステムリブートに近いのですが、インスタンスそのもののリブートのみが必要で、その下のレイヤーのリブートが必要ではないときを指します。このケースの場合、皆様ご自身でリブートのタイミングを決めることができます。つまり、リブートのタイミングを、通常の運用業務にマッチする形で行うなどの選択肢がでてきます。インスタンスリブートが必要になった場合は、そのタイミングが知らされます。そのタイミングより前に皆様ご自身でリブートしていただいても構いませんし(Webコンソール、もしくはAPI経由で)、もしそのタイミングまで何もしなければ、自動的にスケジュールされたタイミングでリブートされることになります。
リタイヤ - 万が一、ハードウェアの調子が悪くこれ以上運用をできないようなケースが起こった際は、インスタンスのリタイヤをスケジュールします。リタイヤがスケジュールされたインスタンスは、その予定された日時以降はterminate(終了)されることになります。もしEBS-backdのEC2インスタンスの場合は、stopしてstartすると他のハードウェア上でインスタンスが立ち上がりますので(S3-backedの場合はAMIをとって立ち上げなおす必要があります)、事前にスケジュールされた時刻以前にその作業をしておく必要があります。もしこのインスタンスが必要でない場合には、スケジュールされた日時以前にterminateしてもよいでしょう。
APIコールについて
DescribeInstanceStatusは、特定のリージョンもしくはアベイラビリティゾーンにてスケジュールされているイベントの情報を返します。各インスタンスについて次の情報が返ります。
- Instance State - インスタンスの状況(pending, running, stopped, or terminated)
- Rebooting Status – インスタンスでリブートがスケジュールされているかどうかを、その予定された日時も含めて (もしあれば)
- Retiring Status - インスタンスでリタイヤがスケジュールされているかどうかを、その予定された日時も含めて(もしあれば).
We'll continue to send "degraded instance" notices to our customers via email to notify you of retiring instances.
Webコンソールのサポート
AWS Management ConsoleのEC2タブの中で、計画されているイベント(Scheduled Events)を見ることができます。
"Scheduled Events"のリンクをクリックすると、詳細を見ることができます。
また、スケジュールされたイベントを持っている各インスタンスについては、時計のアイコンがインスタンスIDの横に表示されます。
管理系のツールなどを作られているパートナー様、ISV様も、このAPIを活用されるに違いありません。もし、適用された場合は、ブログを更新いたしますので、是非ご連絡ください！
玉川憲 (@KenTamagawa)
【AWS発表】 AWS Management ConsoleがAmazon Route 53をサポート
Amazon Route 53(DNSのクラウドサービス)を、AWS Management Console (Webコンソール)から利用することができるようになりました。Route 53は、1ドメインあたり$0.5と非常に定額で、SLA100%を提供するDNSです。これまでのAPI経由や、サードパーティツールのGUIにより利用できたのですが、今回の発表により、各ドメイン(Route 53では、ホスティドゾーンと呼びます)における多種のレコード(A, CNAME, MX等)を、AWSが提供するWebコンソールで利用できるようになりました。
Route 53を利用して、ドメインを登録する典型的な流れは下記になります。
- レジストラからドメイン名を買う
- Route 53でホスティドゾーンを作成する
- レジストラにRoute 53のネームサーバーを登録する
- Webサイトをたてておく
- Route 53でAレコードを作成する
- email用にMXレコードを作成する
今回は、上記の流れをひとつずつ紹介していきます。さらに、おまけとして、重みづけラウンドロビン(WRR) DNSの設定もみてみましょう！
レジストラからドメイン名を買う
まずはレジストラからドメイン名を買いましょう。登録したいトップレベルドメイン(TLD)を扱っているレジストラを選択しましょう。レジストラでドメイン名を買う手順は、レジストラによって異なることにご注意ください。日本のレジストラの一覧に関してはこちらのリンクが参考になるかもしれません。
今回の手順では、例として、cloudcloudcloudcloud.comのドメインを買うとします。その際に、DNSホスト名を登録する場面がでてきますが、そこは後ほど設定するので、現時点では、そのままのデフォルトのものにしておきます。
Route 53で、ホスティドゾーンを作成する
次のステップは、Management ConsoleのRoute 53タブから、下記のボタンを押して、ホスティドゾーンを作成します。
下記の情報を入力します。
ホスティドゾーンが作成され、このゾーンのためのネームサーバーのリスト(Delegation Set)が表示されます。
これをコピーしてとっておきます。
レジストラに、Route 53のネームサーバーを登録する
次に、さきほど取得したリストを、DNSのネームサーバーとして、レジストラに登録します。
このレジストラの例の場合は、既存のレコードを消去し、新しく得たリストを登録します。
Webサイトをたてておく
ここで、実際に名前解決を行う対象となるWebサイトをたてておきましょう。S3の静的Webホスティング機能を用いてWebサイトを立てても良いですし、単独のEC2インスタンスでWebサイトを立てる、もしくは、ELB(ロードバランサ)の後ろにEC2インスタンスでWebサイトをたてても構いません。
ここでは、EC2インスタンスを使うことにします。例えば、一つのEC2サーバーでバーチャルホスティングをしてもよいでしょう。例えば以下のようにします。
Route 53で、Aレコードを作成する
次に、Aレコードを作成します。今回は、EC2でEIP(固定アドレス)を使っていいるので、そのIPアドレスにwwwをマッピングします。
コンソールでAレコードを作りには、"Go to RecordSet"ボタンを押します。
リソースの名前にwwwを入力し、IPアドレスを入力します。
これにより、Route 53は数秒でレコードを反映しますので、www.cloudcloudcloudcloud.comをWebブラウザでみると、すでにWebサイトにアクセスできることがわかります！
email用に、MXレコードを作成する
MX (Mail Exchange)レコードは、メールをルーティングするのに用いられます。emailサーバーをEC2上でホストすることもできますし、外部のemailサービスプロバイダーを用いることもできます。今回は、外部のプロバイダーを用いてみましょう。
Route 53では、下記のように設定します。Valueのフィールドは、用いたemailサービスプロバイダーのものを入力します。
うまく設定できると、下記の例のように(Jeff Barrがamzonから、cloudcloudcloudcloud.comにメールを送信した例)、メールを受信することができます。
重みづけラウンドロビン(WRR) DNSの設定
これまででRoute 53の基本的な使い方をみてきたのですが、ここでは、重みづけラウンドロビン(WRR)の機能をみてみましょう。WRRを用いると、トラフィックをある比率でサーバーに振り分けることができます。注意すべき点としては、ロードバランサのように実際のトラフィックを負荷分散しているのではなく、DNSの名前解決の際に振り分けている点です。
WRRを利用するには、もちろん、複数のサーバー(それぞれIPアドレスを持ったもの)を用意しておく必要があります。例えば、75.101.154.199(本番環境用)と107.20.250.2(テスト用)を利用するとします。各レコードに、3と1の重みをセットします。その重みの配分にそって、DNSルックアップの結果が戻ることになります(つまり、4分の1のみがテスト用サーバーのアドレスを返す)。
本番用 ("Production")の設定は、こちらです。
テスト用 ("Test")の設定はこちらです。
さあ、いかがでしたでしょうか？やはりWebコンソールがあると楽にRoute 53を使えますよね！
玉川憲 (@KenTamagawa)
最近のコメント