UDPをつかって簡単かつ高速にAWSとのデータのやりとりを実現する方法を解説しました。異なるリージョンでのEC2インスタンス間で高速にデータを動かせます。S3にデータを動かせます。UDPは無料で、簡単にセットアップできますが、欠点もあります。センシティブなデータを扱うために必要なネイティブの暗号化機能がありません。シングルスレッドのアプリケーションであること、2009年以降の更新がないこと、商用サポートもありません。UDPはネイティブのS3インテグレーション機能はありません。CLIなどを使ってS3に送信する必要があります。IncによるExpeDatは、それらの不足を解決します。オンプレミスや別リージョンのEC2インスタンスからS3への巨大なデータファイルの移動をシームレスに行えます。UDPと違うのは、ExpeDatはアクティブにメンテナンスされ、フルサポートの製品であり、AES暗号をサポートし、GUIを含むクロスプラットフォームで動作する高速なアプリケーションです。ExpeDatはオブジェクトハンドラを有しており、外部スクリプトやプログラムと統合して、自動化を簡単に実現できます。低レベルでの統合が必要であれば、SDKもあります。Gatewayは自動でデータをS3に入れることができます。gatewayが動作しているEC2ホストのメモリだけを使って、選択したS3バケットにデータ転送ができます。Marketplaceから行います。subscriptionもあります。Gatewayのセットアップは数分で行うことができます。Setsを使うことにします。Gatewayのフリートライアル版EC2インスタンスにデータを移動させてみましょう。ap-northeast-1:s3://accel-file-tx-demo-tokyoにあります。trialへすすみます。21日間はソフトウェア費用はかかりませんが、通常のAWS費用はかかります。リージョンで起動します。ここでは、ExpeDatコマンドラインクライアントを使用していますが、MacやWindows用のGUIツールをダウンロードして使うこともできます。S3インスタンスで"servedat"というサーバアプリケーションを動作させ、S3バケットを設定します。(Tokyo)で起動します。このテストでは、us-east-1で動作させているインスタンスタイプと同じものを選択します。templateを用意しています。AMIを2つ以上の大きなEphemeralドライブを有効にして起動します。/mnt/bigephemeralにマウントします。S3インスタンスからダウンロードします。clientから入手できます。CloudFormationで起動したEC2インスタンスにコピーします。SSHでつかうTCP22がオープンしていれば、SCPを使うことができます。CloudFormationでつくったインスタンスにSSHでログインします。OSのパラメータをUDPバッファを大きくし、スループットが上がるように設定します。guidanceも参考になります。いう名前のファイル転送クライアントをインストールします。このために、ExpeDatのアーカイブ・ファイルを展開し、install-movedat.shを走らせます。“fallocate”コマンドを使って650GBのテストファイルを作ります。IP]:=S3別の方法として、datasetファイルからtarballを作り、ExpeDatのmovedatにパイプします。IP]:=S3ファイル転送が完了すると、S3バケットに現れます。フォルダを監視したり、S3へマニュアルでアップロードする必要もありません。S3に送れば、S3バケットへの転送ができます。AES-128を使うには、movedatコマンドに-Kオプションを使います。UDPには無い機能です。暗号化転送を有効にすると、サーバとクライアントのCPU付加が上昇します。高速なネットワークをつかっていたり、忙しいサーバではパフォーマンス低下にも注意します。S3の利用例はS3バケットでのリスト、リネーム、デリート、ダウンロードです。ExpeDatをつかった複雑なS3オブジェクトの扱いは複数のツールを使うことなしに実現できます。localfile.gzConclusionビッグデータの世界は進化しており、バッチプロセスからリアルタイムやニアリアルタイムになってきています。Gatewayのようなツールは、S3との統合を高速かつシームレスに行うことで、巨大なデータをAWSに移動しなければいけないビジネスニーズ実現を簡単にします。オンプレミスや他のリージョンにあるデータをS3に移動し、EMRやRedshiftでの分析には必要になるでしょう。UDPのようなフリーのツールをしのぐGUIやCUI、あるいは暗号化といった機能が加えられています。様々なオプションのあるCLIにより、複雑なファイルのワークフローの自動化を簡単にします。クライアントSDKをプログラム内で使うこともできます。Expeditionによって活発にメンテされ、フルサポートが提供されていることかもしれません。Marketplaceを通じて簡単にインストールすることがででき、必要なGBコストもとても安いです。フリートライアルもあるのでお試しください。疑問や質問は、どうぞコメントの形でお残しください。AWSのプリンシパルソリューションアーキテクトです。Studioのバージョン1.9.0をリリースしました。Lambdaはプレビュー中のあたらしいコンピュートサービスで、イベントに対応した自分のコードの実行と、コンピュートリソースの自動的な管理によりあたらしい情報に迅速に対応するアプリケーションを作成することがかんたんにできるようになります。Studioプラグインと統合されています。Lambdaへのデプロイがかんたんにできます。Lambdaファンクションの開発とデプロイのプロセスをウォークスルーしていきましょう。プロジェクトのセットアップはじめるためには、新しいプロジェクトを作成する必要があります。Lambdaプロジェクトのテンプレートがあります。Lambdaプロジェクトウィザードをはじめるには3通りのやり方があります。ひとつめのオプションは開発とテストをはじめるための最低限をみたすだけのシンプルなプロジェクトを作成することです。ふたつめのオプションとしてすでにデプロイされたファンクションのソースをプルダウンで選択できます。最後のオプションはサンプルからプロジェクトを作成することです。Creator」のサンプルを選択してFinishをえらびます。ファンクションがデプロイされると、画像がS3バケットにアップロードされたときに呼び出せるようになります。このファンクションは画像をサムネイルにリサイズして、そのサムネイルを別のバケットにアップロードします。サムネイルの宛先のバケットはオリジナルの画像があるバケットと同じ名前に"-thumbnails"サフィックスがついたものになります。プロジェクトは3つのファイルとそれが依存するNode.jsパッケージをセットアップします。CLIと依存関係があります。LambdaはLambdaファンクションを実行できるようにコンピュートインスタンス上にImageMagickを事前に構成します。それでは、プロジェクトに追加されたファイルを見てみましょう。app.jsイベントを受け取ったときにLambdaが呼び出すファンクションを定義します。_sampleEvent.jsonS3からのイベントがどうなっているかをしめす例です。_testdriver.jsLambdaファンクションがローカルに実行する実際のコードです。_sampleEvent.jsonファイルを読んでapp.jsで定義されたLambdaファンクションに渡します。.NETとは別のパスから探索されます。Credentialsファイルをみています。documentationを参照してください。ローカルで実行するサンプルを動かすためには、ソースとターゲットのS3バケットを作成する必要があります。Explorerによりバケットを作成します。2つめのバケットはソースと同じ名前に"-thumnails"サフィックスをつけて作成します。foobarとfoobar-thumbnaisという名前の組み合わせでバケットをつくることができます。注:_testdriver.jsではus-west-2リージョンがデフォルトになりますので、バケットを作成したリージョンにあわせて更新するようにしてください。バケットがを作成してからソースのバケットに画像をアップロードしますので、テスト用の画像を用意しておいてください。keyプロパティをアップロードした画像にあわせて更新します。Studioプロジェクトと同じようにして実行とデバッグができるようになりました。_testdriver.jsを開いてブレイクポイントをセットし、F5を押してデバッガを起動します。Lambdaにファンクションをデプロイするファンクションがローカルで正常に動作することを確認したら、デプロイの時間です。Lambdaを選択します。Functionダイアログが開きます。Nameを入力する必要があります。NameとHandlerフィールドはデフォルトのままにしておけます。Lambdaがファンクションを呼び出すためのIAMロールを構成する必要があります。CloudWatchへのアクセスを選択したあたらしいロールを作成しています。Logsに書き込むことができるため、CloudWatchへのアクセスをつけると、ファンクションの利用状況の監視がとても便利になります。ファンクションをアップロードしてからもいつでもこれらの権限を変更することができます。すべてをセットしたらOKをえらんですすみましょう。アップロードか完了すると、Lambdaファンクションのステータスビューが表示されます。S3の指定になります。そのためには、Addボタンをクリックしてイベントソースを追加します。bucketを選択します。S3にはイベントをLambdaに送るための権限が必要になります。これはロールをイベントソースに関連付けることでおこないます。デフォルトでは、ダイアログによりS3に権限を付与するロールを作成します。イベントソースからS3への構成は実際にはS3バケットの通知設定でなされるため一意になります。このダイアログでOKをえらぶと、イベントソースはここにでてこなくなりますが、バケットを右クリックしてプロパティを選択すると表示されます。ファンクションがデプロイされてS3がファンクションにイベントを送れるように構成され、画像をソースバケットにアップロードしてテストできるようになりました。画像をソースバケットにアップロードしてすぐに、サムネイルがサムネイルバケットに表示されるようになります。S3ブラウザを呼び出すファンクションがあたらしいアップロードされた画像のサムネイルを作成するようにセットアップされました。Functionをえらぶことでできるようになります。つぎに呼び出したいファンクションを選択してOKをえらびます。するとToolkitがS3がLambdaにおくるイベントオブジェクトを作成してファンクションを呼び出します。これはS3ブラウザから複数のファイルやフォルダを選択することでそれぞれのファイルに対しておこなうことができます、これはLambdaファンクションに対してコード変更をしてバケットにあるすべてのオブジェクトにあたらしいコードで再処理させたい場合に便利です。Lambdaでつかえる単なるひとつの例ですが、Lambdaのイベントベースのコンピュートパワーの力を利用する多くのやり方が思い浮かぶのではないかと思います。Streamsにイベントソースを作成することができます。SDKをつかった自分自身のカスタムイベントから呼び出すことも可能です。ToolkitのあたらしいLambdaの機能をためしてどう思うかをお知らせください。Lambdaはプレビューなので、新機能やLambdaをうまくつかうために追加できるものがあればフィードバックを熱烈におまちしています。(IAM)のポリシーがあなたの意図したとおりになっているか確認することをお手伝いするために、IAMポリシーの評価を本日(2015年3月25日)にアップグレードすることをお知らせいたしました。このアップグレードは現在すべてのIAMポリシーに対して有効になりました。本日より、IAMポリシーへの変更を保存する際には、まずポリシーがIAMポリシー言語の文法に準拠していることを確認しなければいけません。このアップグレードはあなたが既存のポリシーを更新したり、新しいものを作成した時にだけ適用されます。重要なことは、既に作成されている全てのポリシーはこれまでと同じように機能していることです。あなたのAWSアカウント内で準拠していないポリシーがあった場合、あなたはそれらに対する変更を保存する前に準拠させるようにしなければいけません。あなたのアカウントの中で準拠していないポリシーがあるかどうか確認するには、IAMコンソールにサインインしてください。黄色いバナーがあれば、あなたのAWSアカウントには修正を必要とする準拠していないポリシーがあります。Validatorの使用」や「IAMポリシー言語の文法」を参照してください。このアップグレードに関する詳細に関しては、「ポリシー言語の文法がアップグレードされます」を参照ください。Grammar」も参照することができます。forum」にお越しください。Webinar「春のベーシックサービス祭り月間」が始まります!こんにちは!AWSテクニカルトレーナーの江川大地(@daiti0804)です。Webinarのご案内です。Webinarの資料をご紹介したいと思います。Webinarのご紹介資料をアップロードいたしました。本ウェビナーは、アマゾンデータサービスジャパンのTechメンバがAWSのプロダクトを深堀りして解説するWebセミナーです。毎週水曜18時より放映しております。いうことで、AWSの中でも代表的なサービスをご紹介します。https://connect.awswebcasts.com/ec2/event/registration.htmlセミナー内容:わずか数分間でサーバインスタンスを起動することが可能なEC2は、コンピューティング要件の変化に合わせて、素早く能力を拡張または縮小することができます。コンピューティングの経済性も変革します。使い慣れたオペレーティングシステムやミドルウェアが利用可能であるため、これまでに培って来た技術をそのまま活かすことが可能です。EC2からアタッチして利用するブロックストレージのサービスです。IOPS(SSD)」「マグネティック」、それぞれの使いどころや、EBSが備えるスナップショット機能など、運用に役立つ機能を紹介します。https://connect.awswebcasts.com/vpc-2015/event/registration.htmlセミナー内容:仮想ネットワーク環境をご自身で定義することによって、Webサービスでのパブリックサブネット/プライベートサブネットの分離、データセンターやオフィスとのハイブリッド環境の構築など、自由なネットワーク構成を構築いただくことが可能です。Serviceは、その高い耐久性とアクセサビリティでAWSのコアサービスの一つとして位置づけられています。データの保管だけではなく配信や連携など多彩な機能を持つこのオブジェクトストレージサービスの機能紹介と活用方法を最新Update(イベント通知機能やクロスリージョンレプリケーション)を踏まえながらご紹介致します。EBSの内容をより深く理解いただけます。本資料では、WordPressをベースとしたAWS上でのスケーラブルなWebアプリケーションの構築方法やその注意事項を解説しています。EBSの簡単な内容、使いどころを確認できます。JapanVPCのウェビナーを楽しむためにこちらも初心者向けWebinarからのご案内です。本資料は、AWS上でサービスを構築してみたいけど、ネットワークをどのように構築したら良いか分からないということ向けの資料で、「AWSは初めてなんだけど...」という方でもご理解頂けるような内容となっています。ネットワークが初めてという方向けの書籍もありますので、よければご活用いただき、4/15のWebinarにご参加いただければと思います。JapanS3のウェビナーを楽しむために最後も初心者向けWebinarからのご案内です。本資料はS3の代表的なユースケースの一つであるバックアップについて解説しています。一つの例ですが、こういったユースケースをイメージしながら、4/22のウェビナーにて、S3の詳細を追いかけていただければと思います。クラウドサービス活用資料集に掲載されています。EC2をお届けします。Security)のIT-Grundschutz(セキュリティ確保のための方法論のIT標準)の対象となるお客様のために、新しいセキュリティとコンプライアンスのワークブックをリリースしました。Groupが作成したお客様向けの新しいワークブックです。このワークブックは、AWSを利用してIT-Grundschutzの認定を取得しようとするときに役立つフレームワークを提供します。ITと一緒にお客様向けのコンプライアンスツールとしてこのワークブックを作成しました。このワークブックは、BSI標準の100-1と100-2の要求だけでなく、IT-Grundschutzの外部委託の認定に関する要求についての情報も提供しています。27001の認証も活用することで、お客様の認定取得の準備が可能になります。IT-Grundschutzの対象のお客様は、AWS利用のためのフレームワークとしてこのワークブックを活用できます。ワークブックでは、BSIの要求するコントロールを定義とテストを行うことを手助けし、どのようなコントロールがAWSをベースとした運用に対応するかを提示します(対象:コンピュート、ストレージ、データーベース、ネットワーク、リージョン、アベイラビリティゾーン、エッジロケーション)。ワークブックは、BSIの標準に基づいて、認証を取得する際の必要事項に対応したコントロールを文書化する際のお客様の負担を低減します。お客様は、英語版のAWSコンプライアンスWebサイトか、ドイツ語版のAWSコンプライアンスのWebサイト、もしくは、こちらのPDF版のリンクで、ワークブックをダウンロードできます。このワークブックの参照において、NDA(機密保持契約)は必要ありません。(0)ハイブリッドアーキテクチャでクラウドを利用する際の3つの神話こんにちは。ソリューションアーキテクトの下佐粉(しもさこ)です。Cloud)」(2015年3月10日)を翻訳しました。(※2015/10/23追記:指摘があり、文章の最後をより分かりやすい訳に入れ替えました。Strategyのトップを務める人物で、エンタープライズがAWSを使っていく上での色々な思想や経験をブログで公開しています。この「ハイブリッドクラウド3つの神話」は、おそらく同様の意見を聞いた事がある方も多いのでは、という内容で、クラウドの使い方について改めて考えさせられる内容になっています。デヴィッド・ラッセル私はいくつかのビジネスソリューションをクラウド上に構築することをCIOとしてリードしていく中でハイブリッドアーキテクチャについての自身の見解を作りあげてきました。直近5ヶ月では大企業のCIOやCTOの方たちと何十回もディスカッションをする機会を得て、幸いにもこのトピックについての考えをより深めることが出来ました。並行して私はハイブリッドアーキテクチャに関するブログや記事を多数読みましたが、ハイブリッドアーキテクチャでどのようにクラウドを使うにか、業界の共通認識はまだ存在しないように感じています。企業がクラウドを活用するのには色々な理由があります。クラウドを採用した企業は、敏捷性(アジリティ)の向上、コスト低減、世界展開が可能になる、といったメリットが得られます。私が会話した多くのCIOは、クラウドによって彼らの貴重なリソースをビジネスに利益をもたらさないところから利益を得られるところへ注力させていました。別の言葉で言えば、密に、強固に結合されたインフラを管理する作業を、彼らのブランドとして認識されているプロダクトやサービスを作るためのアクティビティに変えたのです。言うものの、今日の多くのエンタープライズIT組織は、実証済のインフラやガバナンスが存在し、それを日々運営しています。私はこれらのインフラをできるだけ早くクラウドに移行したいと考える多くのCIOと会話しましたが、結局はクラウドへの移行活動はジャーニー(旅路)であって、時間がかかるものだということに気づかされました。このジャーニーの期間中も企業は彼らのシステムを動かし続け、投資から最大の成果を得つづける必要があるのです。Connectを使って、オンプレミスのインフラをAWSに拡張し、ハイブリッドアーキテクチャを作成しているかを説明しました。これが現時点の私にとって説得力のあるハイブリッドアーキテクチャと言えるものですし、多くの企業がクラウドからの利益を最大化するために使っている手法でもあります。ここからさらに進んだハイブリッド周辺の議論は、少し複雑です。私は、最初は良いと感じたが考えを深めるにおいて支持しなくなったクラウドマーケットでよく聞く3つのトレンドがあると考えています。それが以下の3つの神話です:神話1:ハイブリッドは恒久的な終着点である。「恒久的な」はこの考え方を表現するには強すぎる表現でしょう。レガシーシステムを持つ巨大企業はしばしばハイブリッドクラウドアーキテクチャを複数年単位の計画で採用します。企業のクラウド・ジャーニーはそれぞれで異なるものだし、自身が快適と感じる場所を終着点とするものです。近い将来には、ほとんどの企業が自分自身のデータセンターを運営し続けることはなくなるだろうと私は考えています。3年以上未来の話でしょうが、15年以内には確実にそうなっている自信があります。この変革を加速する要素が少なくとも4つあります:1.クラウドの採用が進むにつれ、クラウドプロバイダーの「規模の経済」は成長し続ける。これはいずれにせよクラウド利用者に利益をもたらし続ける。クラウドテクノロジーによるイノベーションは、未だかつてないペースで進む。AWSは2014年に515回の機能拡張を実施した。過去3年間で見ると毎年ほぼ2倍のペースでイノベーションが成長している。企業がビジネスを実施するために利用しているテクノロジー(eメール、オフィスツール、人事ツール、CRM等)のクラウド上での構築が増えてきている。4.企業が利用する技術やビジネスがクラウド上に移行する数は急速に増加している。AWSマーケットプレースやAWSパートナーネットワークをチェックすると状況が分かるだろう。神話2:ハイブリッドによって、オンプレミスインフラとクラウドの間でアプリケーションをシームレスに行き来できる一見これは魅力的に見えますが、前提条件に根本的な問題を抱えています。それはクラウドとオンプレミスで同等の能力が存在すると考えていることです。企業は自社のデータセンターが持っていない能力、すなわち真の柔軟性、セキュリティ、使った分のリソースのみへの支出、継続的な革新、等を得るためにクラウドに移行します。アプリケーションが自社データセンターとクラウドを行き来できるように設計するということは、利用できる機能を最大公約数に制限してしまうという事を意味しているのです。神話3:ハイブリッドによって、アプリケーションが複数のクラウドプロバイダー間でシームレスに結合することができるこの議題は詳しく検討する余地があるように思えます。企業は、自身のビジネスニーズに対応するためにバラエティに富んだ様々なクラウドソリューションを利用しています。場合、ソリューションは企業のデータセンター以外の場所(多くのケースではAWS)で最適に動くようにパッケージされていて、結果として複数のインフラをミックスして使う事になります。これは全く納得できる考え方でしょう。ITエグゼクティブは自社が解決しようとしている課題を認識し、制約の中でベストなツールを選択するようにトライし続ける必要があるからです。私が危惧しているのは、1つのアプリケーションを複数の異なるクラウドプロバイダーにまたがって動かすように設計する罠にはまってしまうことです。異なるクラウドを接続して一緒に動かすことは、大きな達成感をエンジニアに与えるものです。残念ながらこの方法は、ファーストプレースとしてクラウドを活用している企業の生産性向上力を引き下げてしまいます。私にはまるで出発点に戻ってしまったように感じるのです。自社のインフラを管理する代わりに、他の複数のインフラを管理する事になってしまっています。神話2で説明したようにこれは利用できる機能を最大公約数に制限してしまうのです。企業がベンダーとの良好な関係を維持するために、および1つのプロバイダーにベンダーロックインされることを避けるために、この選択(マルチクラウド)をとることはありえます。ベンダーロックインについては、クラウド業界が懲罰的なビジネス戦術(※訳注:ライセンス違反監査による追徴金等)に向かうことはほとんどなさそうですが、大きなクラウドプロバイダーがサービスを辞めてしまうリスクについては考えておく必要があります。一方で、この懸念を最小化するよりよい方法が他にあるように思うのです。企業が、まったく同じIT環境をつねにデプロイできるような自動化技術を使ってアプリケーションのアーキテクチャを作るという方法です。このベストプラクティスは、クラウドの柔軟性(elastic)の特性を活かすものであり、アプリケーションをインフラから分離するものとなります。これがうまくできれば、別のクラウドプロバイダーに移らないといけないことになっても最小限の負担で済ますことができます。技術の選択は時に難しいものであり、しばしば不完全です。ハイブリッドアーキテクチャが必ず不完全な選択であるとは言い切れないでしょう。私はみなさんの考えをぜひ聞きたいと思っています。議論をさせてください。EC2はデフォルトでVPC内にデプロイされるようになっています。EMRのクラスタが動作するためにどのような通信が必要かを理解することが、VPC内にクラスタをデプロイする際に重要になってきています。このポストでは、これらの要件を解説するとともに、実際にVPCを作ってEMRクラスタをデプロイしていきたいと思います。EMRはこの相互通信をVPCが提供するDNSの名前解決によって実現しています。ip-10-128-8-1.ec2.internal)が割り当てられることによりお互いに通信が可能になっています。この名前解決は内部向け、外部向けともにVPC内のDNSサービスによって提供されています。Groupによって管理されています。Hadoop2が必要とする要件Hadoop1の通信要件は非常に単純なものでした。HDFSのDataNodeは、NameNodeによってFQDNの名前解決が行われない場合、IPアドレスを使った通信にフォールバックする仕組みを持っていました。Hadoopプロジェクトが成熟していくにつれ、より洗練されたセキュリティモデルが求められるようになってきました。Kerberos認証や通信暗号化、更には不要なノードがクラスタに参加するのを防ぐために以下のようなHDFSのパラメータなどが導入されてきています。dfs.namenode.datanode.registration.ip-hostname-checkHadoop2ではNameNodeによって名前解決ができないDataNodeはクラスタに参加できないのです。namenodeノード同士が正しく通信できる必要があるという点では、Hadoop1もHadoop2も根幹的なところでは技術的な通信要件は変わりません。Hadoop2ではより多くの制約があります。VPCの設定EMRの管理ソフトウェアはVPCの外部に配置されており、VPC内のクラスタのすべてのノードと正しく通信ができる必要があります。GroupやNACLによって、EMRの管理ソフトウェアやS3エンドポイントとの通信が許可されている必要があります。CloudWatchひよるモニタリング、ログ収集やジョブステップの登録などを行います。gatewayも必要です。現時点では残念ながらNATインスタンスやVGWをデフォルトルートとして利用することはサポートされていません。いった環境で起動を試みた場合、クラスタは下記のようなエラーによりターミネートされます。vpc-a33690c6".更に、NACLによってアクセス制御されているSubnetへのクラスタのデプロイをする際にも、意図しない通信ブロックによってデプロイがうまくいかないことがあります。これは、NACLはセキュリティグループと違って、ステートレスなファイアウォールであるためです。NACLはインバウンド・アウトバウンドそれぞれについて、必要な通信を明示的に許可してやる必要があります。NACLを利用しているSubnetへのクラスタデプロイが必要な際は、EMRが用意しているセキュリティグループの設定を参考に、NACLを設定してあげてください。名前解決とホスト名について理解するVPC内では各ホストはお互いにDNSルックアップを利用して通信できる必要があります。NameNodeのようなプロセスの動作に問題をもたらすでしょう。設定はVPC内にデプロイされるインスタンスにホスト名を割り当てるかどうかを制御します。VPCが提供するデフォルトのDNSであるAmazonProvidedDNSを使っている場合、この設定をオフにすると名前解決ができなくなってしまうので、VPC内のインスタンス同士の通信ができなくなってしまいます。hostnamesが有効なVPCでインスタンスがどのように名前解決をするかを見てみましょう。hostnamesをオフにしてインスタンスを再起動して同じことを試してみます。NXDOMAINご覧のとおり、正引き、逆引きともに失敗します。外部のホスト名解決はできることに注意してください。resolution設定を変更すると、一切にクエリが失敗するようになります。reached名前解決に問題があると、必要なデーモン群が起動しません。EMRではこれらのデーモンが起動してこない限り、クラスタの作成は成功しません。いった問題が発生している場合、下記のようなログが出力されます。ip-192-168-128-13.hadoop.localDNS関連の問題によって発生したエラーは下記のようにクラスタをターミネートします。launch"こういうログが出てくるケースもあります。hostnamesがオフになっている場合)を持っていることを想定しています。カスタムされたドメイン名を使っていても、Hadoop1ではクラスタ起動時に問題は発生しません。カスタムされたドメイン名を利用する場合、VPCがデフォルトで用意するDNSサーバーでは解決できないホスト名を設定値としてもったクラスタを作成します。この場合、Hadoop2のクラスタを利用するためには、これらのカスタムドメイン名を解決できるDNSサーバーを自身で用意する必要があります。EMRのためのVPCを作成するここまでHadoopとEMRの通信要件を見てきましたので、実際に試していきましょう。EMRのクラスタをデプロイするためのVPCを作成します。マネジメントコンソールのVPCウィザードを使ってもいいですし、下記のCLIの手順に沿っても作成できます。今回は/24の小さなVPCを作り、その中に/28のプレフィックスを持ったサブネット群を作成します。IDと利用可能なIPアドレスの数が返ってくるのでメモをとっておきましょう。gatewayに関連付けられたルートテーブルが必要です。いま作成したVPCのIDを使ってcreate-route-table、create-routeとコマンドを発行していきます。vpc-055ef660返ってくるテーブルのIDをメモして下さい。gatewayを作成します。gatewayのIDのメモを取り、次にそれをVPCにアタッチします。gatewayを先ほど作成したルートテーブルのデフォルトルートとして設定します。hostnamesが有効になっているか確認します。なっていなければ有効化します。--enable-dns-hostnamesこれでVPCについてのすべての準備が整いました。jobを実行するEMRクラスタを作成してみましょう。--auto-terminateクラスタのIDが返って来ます。"j-2TEFHMDR3LXWD"}数分待ってから、ジョブが終わったかどうかを確認してみます。completed"うまく動いたと思います!今回、Hadoopの通信要件とVPCとEC2の設定がEMRに及ぼす影響について見てきました。実際にVPCを作成することでデフォルトの設定がEMRクラスタを構成するEC2に提供するもの、設定変更が及ぼす影響などを見てきました。次回以降のポストでは、カスタムDNSを利用する場合の設定について見て行きたいと思います。(0)2015年4月のAWS初心者向けWebinarのお知らせAWSソリューションアーキテクトの舟崎です。4月のAWS初心者向けWebinarのお知らせです。18:00-19:15対象:一般向けAWS初心者向けWebinarでは初のビジネス担当者向けのWebinarとなります。3つのフェイズごとに紹介し解説いたします。提供するセキュリティに関する機能を紹介し、その典型的な使い方やベストプラクティスについて紹介いたします。上でお客様が行うセキュリティ対策にご興味のある方は、是非ご参加ください。詳細・お申込みはこちらAWS初心者向けWebinarとは?AWSをこれからご利用頂くお客様向けのソリューションカットのWebinarです。今までは技術的な内容を中心にお伝えしてきましたが、今回初の試みとしてビジネスユーザ向けのWebinarも開催いたします。AWSの初心者向けのWebinarではありますが、既にAWSをご利用頂いている皆様にも有益なコンテンツとなるよう鋭意資料作成を行っておりますので、AWSを利用中の皆様も是非ご参加ください。Webinarのトピックは、受講頂いた皆様からのご要望に基づいて選定を行っております。Webinarにご参加頂き、ご要望もあわせてお寄せいただければと思います。AWSクラウド活用資料集のページで公開させて頂いております。2015年1月から3月に開催したWebinarの資料は以下となります。PDFイベントの告知について国内のクラウドセミナー・イベントスケジュールにて、随時公開させて頂いております。ご確認の上、ぜひお申込みください。RDSをご利用しているお客様は、すでに、SSL証明書の置き換えを行う旨、AWSからのメールを受信していると思います。5:00AM(JST)に置き換えられます。証明書置き換えは、一般的なメンテナンスであり、RDSのセキュリティベストプラクティスのために行われますが、RDSにおいて、SSLを使用してデータベース接続をしている全てのお客様に、データベースインスタンスの接続性を維持するためのアクションが必要です。このブログの投稿は、これまでのRDSに関するアナウンスの詳細な説明と、お客様がどのような影響を受けるか、データベースインスタンスの接続性を維持するために何をすべきか、について説明をします。SSL証明書の置き換えの通知とはなんですか?一般的なメンテナンスかつ、RDSのセキュリティベストプラクティスである、数年に一度のRDSインスタンスの証明書の置き換えになります。次回の更新が、2015/3/24(JST)に予定されています。この取り組みの一環として、RDSは、データベースインスタンスのセキュリティ強化のため、単一のグローバル認証局から2階層モデルに移行します。RDSは、グローバルX.509証明書をサポートし続けますが、単一のグローバル証明書に代わり、データベースインスタンスごとに、リージョナルな中間証明書を利用した個別の証明書が発行されるようになります。お客様のデータベースクライアントやアプリケーションが、RDSデータベースインスタンスにSSLを使用して接続している場合、2015/3/24(JST)の時点で、クライアントやアプリケーションのSSL証明書を置き換えていないと、データベースインスタンスに接続できなくなります。Serverのデータベースインスタンスを使用しており、お客様のデータベースクライアントやアプリケーションがSSL接続を使用している場合、影響を受けます。Oracleインスタンスは、ネイティブ・ネットワーク暗号化(NNE)を使用しているため影響を受けません。このメンテナンスは、中国(北京)リージョンとGovCloud(US)リージョンのデータベースインスタンスも影響を受けません。5:00AM(日本時間)までに、お客様のデータベースクライアントやアプリケーションのSSL証明書を更新する必要があります。インスタンスへの接続の暗号化」から、SSL証明書をダウンロードしてください。ダウンロードページに記載している手順にしたがって、ダウンロードした新しい証明書をお客様のデータベースクライアントやアプリケーションで使用してください。お客様のクライアントやアプリケーション固有の設定になります。Immediately」をチェックして更新の操作を行い、「rds-ca-2010」から「rds-ca-2015」の証明書へ変更します。この操作は、RDSインスタンスのSSL証明書を更新すると、証明書を有効化するために再起動されます。この再起動は、一般的に完了するまで2分かかります。テーブル数が多い場合は、再起動にもう少し時間がかかることもあります。5:00AM(日本時間)までに行わなくてはなりません。3ステップを実施せずに更新の日時を経過した場合は、お客様のクライアントやアプリケーションは、SSLを使用して、データべースに接続できなくなります。質問や問題がある場合、どうすればよいですか?質問や問題がある場合は、AWSサポートか、テクニカルアカウントマネージャ(TAM)にお問い合わせください。---日本のお客様は、3/5に下記のブログでもアナウンスしています。全国のAWSユーザーの皆様、こんにちは!AWSテクニカルトレーナーの江川大地(@daiti0804)です。始まってから、まもなく1年が経とうとしています。そこで、2015年4月からは再び心機一転ということで、2014年に紹介したサービスも改めて取り上げていこうと思っています。一度取り上げたサービスも、この1年で多くのアップデートがありました。昨日3/19(木)には、EBSの最大容量が16TB、IOPSが20,000IOPSまでに指定可能になるアップデートがありました。知識の棚卸しとともに新たな情報のキャッチアップを行っていきましょう!4月の放映内容について4月から新年度を迎える方も多いかと思います。新入社員の方々や新たにAWSを始めるという方々も多いだろうということで、4月は「春のベーシックサービス祭り月間」としました!AWSを利用する上で、多くの方が使うことになるサービスを経験豊富なソリューションアーキテクト陣が紹介します。https://connect.awswebcasts.com/ec2/event/registration.htmlセミナー内容:わずか数分間でサーバインスタンスを起動することが可能なEC2は、コンピューティング要件の変化に合わせて、素早く能力を拡張または縮小することができます。コンピューティングの経済性も変革します。使い慣れたオペレーティングシステムやミドルウェアが利用可能であるため、これまでに培って来た技術をそのまま活かすことが可能です。EC2からアタッチして利用するブロックストレージのサービスです。IOPS(SSD)」「マグネティック」、それぞれの使いどころや、EBSが備えるスナップショット機能など、運用に役立つ機能を紹介します。https://connect.awswebcasts.com/vpc-2015/event/registration.htmlセミナー内容:仮想ネットワーク環境をご自身で定義することによって、Webサービスでのパブリックサブネット/プライベートサブネットの分離、データセンターやオフィスとのハイブリッド環境の構築など、自由なネットワーク構成を構築いただくことが可能です。Serviceは、その高い耐久性とアクセサビリティでAWSのコアサービスの一つとして位置づけられています。データの保管だけではなく配信や連携など多彩な機能を持つこのオブジェクトストレージサービスの機能紹介と活用方法を最新Updateを踏まえながらご紹介致します。ハッシュタグを利用しておりました。Facebookこのブログの最新情報はTwitter、Facebookでもお知らせしています。お気軽にフォローください。