Author: AWS Japan Staff


新開設 – AWS 米国東部 (オハイオ) リージョン

AWS を拡大するための継続的なプランの一環として、新しいリージョンを開設したことをお知らせいたします。米国東部で AWS をご利用のお客様は、既存の US East (Northern Virginia) リージョンと合わせて、AWS インフラストラクチャサービスのスイートに低レイテンシーで迅速にアクセスできるようになります。

詳細
新しいオハイオリージョンは、Amazon Elastic Compute Cloud (EC2) に加えて Amazon Elastic Block Store (EBS)Amazon Virtual Private CloudAuto ScalingElastic Load BalancingNAT ゲートウェイスポットインスタンスDedicated Host などの関連サービスをサポートします。

まだまだ続きます。Amazon API GatewayAmazon AuroraAWS Certificate Manager (ACM)AWS CloudFormationAmazon CloudFrontAWS CloudHSMAmazon CloudWatch (CloudWatch EventsCloudWatch Logs を含む)、AWS CloudTrailAWS CodeCommitAWS CodeDeployAWS CodePipelineAWS ConfigAWS Database Migration ServiceAWS Direct ConnectAmazon DynamoDBAmazon EC2 Container RegistryAmazon ECSAmazon Elastic File SystemAmazon ElastiCacheAWS Elastic BeanstalkAmazon EMRAmazon Elasticsearch ServiceAmazon GlacierAWS Identity and Access Management (IAM)AWS Import/Export SnowballAWS Key Management Service (KMS)Amazon KinesisAWS LambdaAWS MarketplaceAWS Mobile HubAWS OpsWorksAmazon Relational Database Service (RDS)Amazon RedshiftAmazon Route 53Amazon Simple Storage Service (S3)AWS Service CatalogAmazon Simple Notification Service (SNS)Amazon Simple Queue Service (SQS)AWS Storage GatewayAmazon Simple Workflow Service (SWF)AWS Trusted AdvisorVM Import/ExportAWS WAF もサポートします。

オハイオリージョンは、C4D2I2M4R3T2、および X1 のインスタンスをすべてのサイズでサポートします。他の最近開設されたすべてのリージョンと同様に、インスタンスはリソーススタック内で起動する必要があります (詳細については、「Virtual Private Clouds for Everyone」を参照してください)。

すぐれた接続
以下に参考になると思われるラウンドトリップのネットワークメトリックスをいくつか示します (すべての名前は空港コードです。また、ネットワーキング業界の通例として、すべての時間には +/- 2 ms の誤差が伴います)。

  • IAD (US East (Northern Virginia) リージョンの本拠) とは 12 ms。
  • JFK (インターネット交換ポイントの本拠) とは 20 ms。
  • ORD (QTS および Equinix でホストされている Direct Connect ロケーションと別の交換ポイントのぺアの本拠) とは 29 ms。
  • SFO (US West (Northern California) リージョンの本拠) とは 91 ms。

US East (Ohio)US East (Northern Virginia) のラウンドトリップレイテンシーは 12 ms のみであり、S3 Cross-Region ReplicationCross-Region Read Replicas for Amazon AuroraCross-Region Read Replicas for MySQLCross-Region Read Replicas for PostgreSQL などの AWS 特有の機能を十分に活用できます。2 つのリージョン間のデータ転送には、AZ 間料金 (GB あたり 0.01 USD) が適用されるため、リージョンをまたいだユースケースはより一層経済的なものになります。また、ネットワーキングフロントについては、オハイオ州立大学と協力して OARnet への AWS Direct Connect アクセスを提供することが合意されました。この 100 ギガビットネットワークは、オハイオ州全体の大学、学校、医学研究病院、州政府を接続します。この接続により、地域の教師、学生、研究者は AWS への専用の高速ネットワーク接続を利用できます。

14 リージョン、38 アベイラビリティーゾーン (増加中)
このリージョン (3 つの AZ で構成) が本日開設されたことで、AWS は総計 14 リージョンおよび 38 アベイラビリティーゾーンに拡大されました。また、中国で 2 番目の AWS リージョンの開設準備中であり、カナダ、フランス、英国でも新しい AWS リージョンが計画されています。

最近、リージョンとアベイラビリティーゾーンの違いについて業界全体で混乱があるようですが、この 2 つの用語の違いをよく理解しておくことが重要です。各リージョンは、1 つ以上のアベイラビリティーゾーン (AZ) で構成される物理的な場所を指します。各アベイラビリティーゾーンは、1 つ以上のデータセンターで構成されます。各データセンターは、冗長性のある電源、ネットワーキング、および接続を備えており、それぞれが別々の設備に収容されます。各リージョンに複数の AZ を設けることで、AZ が 1 つだけの場合よりも、実行するアプリケーションの可用性、耐障害性、耐久性を強化できます。

2 つの用語の違いを説明するために仲間内でよく使う例えがあります。私の好きな例えは、「ホテルとホテル内の部屋」、「リンゴの木とリンゴ」です。何に例えても構いませんが、違いをよく理解した上で使ってください。

Jeff;

Amazon ElastiCache for Redisアップデート – Sharded Clusterの追加やエンジンバージョンを更新 –

多くのAWSのお客様に高速で、インメモリデータストアとして Amazon ElastiCacheをご利用頂いています。

2013年にAmazon ElastiCache for Redisリリースし、スナップショットのS3へのエクスポート機能エンジンバージョンの更新スケールアップ機能タグMulti-AZで自動フェイルオーバー機能を数年で追加してきました。

本日、新機能をElastiCache for Redisへ追加しました。詳細は以下の通りです。

  • Sharded Clusterサポート – 3.5 TiB以上をインメモリデータとして扱う事が出来るsharded clusterを作成可能になりました
  • コンソールの改善 – 以前より簡単にクラスタの作成やメンテナンスが行えるようになりました
  • エンジンアップデート – Redis 3.2の機能をご利用頂けるようになりました
  • Geospatial Data – 地理空間データの処理を行え、利用可能になりました

更に詳細を見ていきましょう!

 

Sharded Clusterサポート / 新コンソール

今まではElastiCache for Redisは1つのプライマリノードと5つまでのread replicaを含んだクラスタに対応していました。この構成では、メモリサイズがクラスタあたり237 GiBに制限されていました。

1クラスタで15シャードまで作成出来るようになったことで、クラスタ全体のメモリ容量を拡大することが可能になり、最大3.5 TiBまでのデータをインメモリデータとして格納出来ます。それぞれのシャードは5つまでread replicaを作成可能で、1秒あたり2,000万読み込み、450万書き込みの性能を提供します。

シャードモデルは、read replicaと合わせて利用することでクラスタ全体の可用性とパフォーマンスを向上します。データは複数のノードに分散され、read replicaは高速で自動的なフェイルオーバーをプライマリノードに障害が起こった際に提供します。

シャードモデルの利点を活かすために、cluster対応のRedisクライアントを使う必要があります。クライアントは、16,384個のスロットをシャード毎に均等に分散されたハッシュテーブルとして扱い、保存するデータを各シャードにマップします。

ElastiCache for Redisはクラスタ全体を1つのバックアップとリストア用途のユニットとして扱います。そのため、各シャード毎のバックアップを管理したり考えたりする必要がありません。

コンソールの機能が改善され、スケールアウトクラスタを簡単に作成可能になりました。(Redisエンジンを選択した後にCluster Mode enabled (Scale Out)にチェックを入れている点を注目して下さい)

ec_redis_create_so_cluster

新しい便利なメニューで適切なノードタイプを選択を手助けしてくれます

ec_redis_pick_your_node_not_your_nose

sharded clusterは、AWS Command Line Interface (CLI)AWS Tools for Windows PowerShellElastiCache APIAWS CloudFormationテンプレートからも作成可能です。

 

エンジンアップデート

Amazon ElastiCache for RedisはRedis3.2に対応しました。このバージョンは3つの興味深い機能を持っています。

  • Enforced Write Consistency – 新しいWAITコマンドはそれ以前の全ての書き込みコマンドに対して、プライマリノードと設定された数のread replicaから確認応答が返ってくるまで呼び出し元をブロックします。この変更はRedisを強い一貫性を持ったデータストアにするものではありません。しかし、新しく昇格したread replicaが直前にプライマリノードに書き込まれた出たデータを保持している可能性を向上します
  • SPOP with COUNTSPOPコマンドはsetからランダムにエレメントを削除してそれを返却します。1つ以上のエレメントを1回でリクエスト出来るようになりました
  • Bitfields – BitfieldsはRedis stringとして保存されていた小さい整数のコレクションをビットマップとして保存することでメモリ効率を良くする方法です。BITFIELDコマンドを使うことで、 (GET) や(SET, increment, decrement) をbyteアライメントや文字境界を気にすること無く扱うことが出来るようになります

私達のRedisの実装は、サーバプロセスをフォークする事なくスナップショットを取得する機能を持っています。過負荷状態では標準のフォークを利用したスナップショットはスワップによるパフォーマンスの低下を引き起こす可能性があります。私達の実装ではメモリ利用率が50%を越えていたとしても動作をし、問題を解決します。この機能は少し低速なため、必要になった場合にこの機能を利用します。

その他にも私達の実装では新しいread replicaがプライマリノードと同期する時のパフォーマンスを向上しています。これと似た性能向上を新しく昇格したプライマリノードと既存のread replicaが同期する際にも実装しています。

今までお伝えした通り、私達のエンジンはオープンソースバージョンのものと互換性があり、皆様のアプリケーションに変更は必要ありません。

 

Geospatial Data

地理空間データ(緯度・経度)を保存したりクエリ出来るようになりました。以下が関連するコマンドです。

  • GEOADD – 地理空間データを保存
  • GEODIST – 2地点間の距離を取得
  • GEOHASHGeohash (geocoding)を取得
  • GEOPOS – keyでしてされた地点のアイテムを取得
  • GEORADIUS – 指定された地点の半径内のアイテムを取得
  • GEORADIUSBYMEMBER – 他のアイテムの半径内に収まるアイテムを取得

 

今日からご利用頂けます

Sharded clusterを含む今回ご紹介した全ての機能は全てのAWSリージョン今日からご利用頂けます。

Jeff; (翻訳は星野が担当しました。原文はこちら)

現在進行中 – VMware Cloud on AWS

オンプレミスの仮想化への長期的なトレンドにより、多くの企業は業務効率を向上させ、データセンターから可能な限り多くの価値を引き出しています。その過程で、アーキテクチャのスキルと業務経験のレパートリーを大きく広げることができましたが、現在ではパブリッククラウドのエコノミクスや AWS の技術革新のペースに合わせるべく苦労しています。このため、多くのエンタープライズは AWS Cloud に注目しています。企業は、AWS が世界の 13 か所 (さらに 5 か所で工事中) にある 35 のアベイラビリティーゾーンにデータセンターを持っていることに注目し、豊富な AWS サービスや柔軟性の高い従量課金制モデルに大きな価値を見出しています。また、多くの場合は 10 年以上も前からの仮想化への投資を基にして将来的に物事を進める方法を模索しています。VMware + AWS = 勝利
これらの組織が仮想化への既存の投資を基にしながら、AWS が提供するメリットを活用することを支援するため、当社は VMware の仲間と連携して、VMware Cloud on AWS を構築、提供するべく努力しています。

この新しいサービスは AWS クラウドでのネイティブな完全マネージド型 VMware 環境で、時間単位のオンデマンド、またはサブスクリプション形式でアクセスできます。これには、vSphere Hypervisor (ESXi)、Virtual SAN (vSAN)、および NSX ネットワーク仮想化プラットフォームを含めて、今日お客様が自社のデータセンターで実行できるのと同じコア VMware テクノロジーが含まれ、クリーンでシームレスな体験を提供するよう設計されています。

VMware Cloud on AWS は物理ハードウェアで直接実行される一方で、当社のセキュリティファーストの設計モデルをサポートするべく設計されたネットワークとハードウェア機能のホストを活用します。これにより、VMware はネストされた仮想化を使用することなく、AWS インフラストラクチャで仮想スタックを実行できます。

お客様が、上記に説明したような状況 (オンプレミスの仮想化を実行しているが、クラウドを検討している) にある場合、この方法が気に入ると思います。パッケージング、ツール、およびトレーニングの投資は引き続き効果を生み出します。既存の VMware ライセンス、契約、および割引も同様です。ESXi、vSAN、および NSX に関するお客様とチームのすべての知識は、そのまま活用することができます。vCenter の既存のコピーや、vCenter API を利用するツールとスクリプトを使用して、VMware 環境全体 (オンプレミスおよび AWS) を管理できます。

AWS コンピューティングストレージデータベース分析モバイル、および IoT サービス全体は、アプリケーションから直接アクセスできます。VMware アプリケーションは AWS サービスと同じデータセンターで実行されるため、これらのサービスを使用してアプリケーションを強化または拡張するときに使用する、高速、低レイテンシーの接続によるメリットがあります。AWS Database Migration ServiceAWS Import/Export SnowballAWS Storage Gateway などの AWS 移行ツールを利用することもできます。

豊富なオプション
VMware Cloud on AWS には、移行、データセンター統合、更新、グローバル化に関して多くのさまざまなオプションが用意されています。

移行に関しては、vSphere vMotion を使用して、わずかなクリック操作で個別の VM、ワークロード、またはデータセンター全体を AWS にライブ移行できます。また、個別のコンポーネントを移行する際に、AWS Direct Connect を使用して、施設から AWS への専用ネットワーク接続をセットアップすることができます。

データセンター統合については、既存の業務手法、ツール、またはポリシーを変更することなく、コードとデータを AWS に移行できます。

更新の準備ができたら、Amazon Aurora (MySQL と互換性を持つよう設計された高度にスケーラブルなリレーショナルデータベース)、Amazon Redshift (高速で完全マネージド型、ペタバイト規模のデータウェアハウス) や、その他多くのサービスの独自で強力な機能を利用できます。

ビジネスをグローバル化する必要がある場合は、わずかなクリック操作により複数の AWS リージョンで既存のアプリケーションを起動できます。

お楽しみに
この開発の詳細情報は、利用可能になり次第お知らせいたします。詳細については、VMware Cloud on AWS ページをご覧ください。

Jeff;

Atlassian JIRA ソフトウェアと Bitbucket データセンターの新しい AWS クイックスタート

AWS クイックスタートは AWS Cloud 内のソフトウェアソリューションのリファレンス実装を迅速にデプロイする場合に役立ちます。クイックスタートを使用すれば、AWS やソフトウェアパートナーが推奨しているベストプラクティスのメリットを活用しながら簡単にソフトウェアをテストしたり使用することができます。

今回は APN アドバンスドテクノロジーパートナー (および DevOps コンピテンシー所有者) である Atlassian と協力して開発したクイックスタートガイドのペアについてご紹介します。このクイックスタートガイドは JIRA ソフトウェアデータセンターAWS 上の Bitbucket データセンターのデプロイで役立ちます。

Atlassian のデータセンターの機能は、規模の大きな開発チームを持ち、スケーラブルで可用性の高い開発ツールとプロジェクト管理ツールを必要とするお客様のために設計されています。こうしたツールは常にミッションクリティカルであるため、堅牢性と耐障害性がベースライン要件であり、実稼働デプロイメントは常にマルチノードまたはクラスター設定で実行されるようになっています。

新しいクイックスタート
JIRA ソフトウェアデータセンターはスピードを必要とするチームにプロジェクト管理ソリューションと問題管理ソリューションを提供、Bitbucket データセンターは Git リポジトリソリューションを提供します。どちらのソリューションも、複数のプロジェクトに携わる規模の大きなチームで可用性が高く大規模なパフォーマンスを実現します。こうした新しい Atlassian クイックスタートにより、徹底的なテストとリファレンスアーキテクチャの完全サポートを利用することができるので、AWS で行う製品のデプロイを大幅に簡略化し加速することが可能になりました。

クイックスタートには、新規または既存の Virtual Private Cloud (VPC) で Bitbucket と JIRA ソフトウェアのデプロイを許可する AWS CloudFormation テンプレートが含まれています。新しい VPC を使用したい場合は、テンプレートが作成できます。同時にパブリックサブネット、プライベートサブネット、NAT ゲートウェイも作成するので、プライベートサブネットで EC2 インスタンスを許可しインターネットに接続することができます (NAT ゲートウェイを利用できないリージョンでは、代わりに NAT インスタンスをテンプレートが作成します)。すでに AWS をご利用されていて適切な VPC がある場合は、代わりに JIRA ソフトウェアデータセンターと Bitbucket データセンターをデプロイすることができます。

起動したい Atlassian 製品の評価版ラインセンスにサインアップしてください。

Bitbucket データセンター
Bitbucket データセンタークイックスタートはデプロイの一部として次のコンポーネントを実行します。

Amazon RDS PostgreSQL – Bitbucket データセンターはサポート対象になっているデータベースを必要とします。マルチ AZ 設定の Amazon RDS for PostgreSQL はマスターノードが失敗した場合にフェイルオーバーを許可します。

NFS サーバー – Bitbucket データセンターは共有ファイルシステムを使用して、複数の Bitbucket ノードがアクセスできる一般的な場所にリポジトリを保存します。クイックスタートアーキテクチャはアタッチしている Amazon Elastic Block Store (EBS) ボリュームを使用した EC2 インスタンスで共有ファイルシステムを実装します。

Bitbucket Auto Scaling グループ – Bitbucket データセンター製品は Auto Scaling グループの Amazon Elastic Compute Cloud (EC2) インスタンスにインストールされています。デプロイのスケールアウト/インは使用率により異なります。

Amazon Elasticsearch Service – Bitbucket データセンターはインデックス作成と検索に Elasticsearch を使用します。クイックスタートアーキテクチャは Amazon Elasticsearch Service を使用します。これは AWS クラウドの Elasticsearch でデプロイ、操作、スケールを行いやすくするマネージドサービスです。

JIRA ソフトウェアデータセンター
JIRA ソフトウェアデータセンタークイックスタートはデプロイの一部として次のコンポーネントを実行します。

Amazon RDS PostgreSQL – JIRA データセンターはサポート対象になっているデータベースを必要とします。マルチ AZ 設定の Amazon RDS for PostgreSQL はマスターノードが失敗した場合にフェイルオーバーを許可します。

Amazon Elastic File System – JIRA ソフトウェアデータセンターは共有ファイルシステムを使用して、複数の JIRA ノードがアクセスできる一般的な場所にアーティファクトを保存します。クイックスタートアーキテクチャは Amazon Elastic File System を使用する可用性の高い共有ファイルシステムを実装します。

JIRA Auto Scaling グループ – JIRA データセンター製品は Auto Scaling グループの Amazon Elastic Compute Cloud (EC2) インスタンスにインストールされています。デプロイのスケールアウト/インは使用率により異なります。

今後も Atlassian と協力し、この新しいクイックスタートの更新と改善を実現していきます。この他にも Atlassian Confluence と Atlassian JIRA サービスデスクのクイックスタートの作成にも取り組んでおり、AWS re:Invent までにはリリースしたいと考えています。

開始するには Bitbucket データセンタークイックスタートまたは JIRA ソフトウェアデータセンタークイックスタートをご覧ください。また Atlassian のクイックスタートページもご覧ください。テンプレートは今すぐご利用いただけます。ぜひご感想をお寄せください!

Jeff;

AWS オンラインセミナー – 2016 年 10 月 & 11 月(太平洋時間・英語によるセミナー)

AWS による開発事項の最新情報をご存知ですか?Amazon RedshiftAmazon ECSAmazon Cognito について十分理解していますか?IoT について理解し、クラウドのワークロードに適用するセキュリティのベストプラクティスをしっかり把握していますか?EC2 スポット市場を把握し、その活用方法を理解していますか?

トレーニングと教育面に焦点を当てた 10 月と 11 月に開催予定の AWS オンラインセミナーについては次をご覧ください。受講は無料ですが、すぐに満席になってしまうため、お早目の登録をお勧めします。開催時間はすべて太平洋標準時、所有時間は 1 時間です。

10 月 25 日

10 月 26 日

10 月 27 日

11 月 8 日

11 月 9 日

11 月 10 日

Jeff;


 
PS – re:Invent 2016 の準備に関するオンラインセミナーをお忘れなく!

X1 インスタンスの更新 – X1.16xlarge + リージョンの追加

今年初旬に AWS は x1.32xlarge インスタンスをリリースしました。約 2 TiB の容量を備えるこのインスタンスタイプは、メモリに大きな負担をかけるビッグデータ、キャッシュ、分析などのワークロードに最適です。AWS のお客様は SAP HANA インメモリデータベース、大規模な Apache Spark や Hadoop ジョブ、様々なタイプのハイパフォーマンスコンピューティング (HPC) ワークロードを実行しています。

そしてこの度、AWS は X1 インスタンスタイプの更新を 2 つリリースしました。

  • 新しいインスタンスのサイズx1.16xlarge インスタンスの新しいサイズはフットプリントが小さいワークロードの実行を可能にします。
  • 新しいリージョン – X1 インスタンスの利用が可能なリージョンを 3 つ追加しました。これでリージョン数は合計 10 になりました。

新しいインスタンスのサイズ
新しい x1.16xlarge の仕様は次のとおりです。

  • プロセッサ: 2 x Intel™ Xeon E7 8880 v3 (Haswell) 2.3 GHz – 32 cores / 64 vCPUs で実行
  • メモリ: Single Device Data Correction (SDDC+1) 使用の 976 GiB
  • インスタンスストレージ: 1,920 GB SSD
  • ネットワーク帯域幅: 10 Gbps
  • 専用の EBS 帯域幅: 5 Gbps (追加料金なしで EBS の最適化)

x1.32xlarge のように、このインスタンスは Turbo Boost 2.0 (最大 3.1 GHz)、AVX 2.0AES-NITSX-NI をサポートします。こうしたインスタンスは、オンデマンドインスタンススポットインスタンスまたは専有インスタンスとしてご利用いただけます。また、リザーブドインスタンスDedicated Host の予約を購入することもできます。

新しいリージョン
X1 インスタンスの両サイズは次のリージョンで利用可能です。

  • US East (Northern Virginia)
  • US West (Oregon)
  • Europe (Ireland)
  • Europe (Frankfurt)
  • Asia Pacific (Tokyo)
  • Asia Pacific (Singapore)
  • Asia Pacific (Sydney)
  • Asia Pacific (Mumbai) – New
  • AWS GovCloud (US) – New
  • Asia Pacific (Seoul) – New

Jeff;

週刊 AWS – 2016 年 10 月 3 日

今回の週刊 AWS の作成には AWS 内外から 20 人の寄稿者にご協力いただきました。自分もぜひ参加していみたいという方は (re:Invent でランチ無料の可能性あり)、GitHub の週刊 AWS をご覧ください。

月曜日

10 月 3 日

火曜日

10 月 4 日

水曜日

10 月 5 日

木曜日

10 月 6 日

金曜日

10 月 7 日

土曜日

10 月 8 日

  • 何もありませんでした。
日曜日

10 月 9 日

新しい AWS Marketplace の製品

新しい & 注目のオープンソース

  • elastic-ci-stack-for-aws は、お客様の VPC で実行中のビルドエージェントのシンプルで柔軟性の高い Auto Scaling クラスターです。
  • aws-lambda-ebs-backups には、EBS ボリュームのスナップショットのバックアップや削除を行うために AWS Lambda サービスを使用して実行する Python スクリプトが含まれています。
  • load-dyno-table は DynamoDB テーブルローダーです。
  • letsencrypt-iam-lambda は受け取った S3 イベントを処理し、AWS IAM の関連する証明書を更新する AWS Lambda 関数です。
  • sundial は依存関係およびスケジューリングを管理する Amazon EC2 Container Service のジョブシステムです。
  • jrestless は AWS Lambda を使用してサーバーレスアーキテクチャで JAX-RS アプリケーションを構築するのに役立つフレームワークです。
  • AWSLambda_CloudFrontMetaData は CloudFront への顧客の訪問からメタデータ (IP バージョン、HTTP バージョン、エッジロケーション) を抽出する Lambda 関数です。
  • hologram は AWS 認証情報を簡単かつ容易に開発者のノートパソコンへ実装します。
  • og-aws は AWS の実践ガイドです。
  • aws-secrets は EC2 インスタンスの秘密情報を KMS 暗号化、IAM ロール、S3 ストレージにより管理するのに役立ちます。

新しい YouTube 動画

近日開催のイベント

サポート募集

来週をお楽しみに。それまでは、Twitter でフォローして、RSS フィードをサブスクライブしてね。

AWS ブログのユーザビリティパネル (シアトルまたはリモート)

今後も AWS ブログを通じて読者の皆さんが必要とする情報やエンターテインメントを提供していくため、今月下旬にユーザビリティパネルの開催を企画しています。初心者から上級者まで、ブログの読者や AWS をご利用されているローカル (シアトル) にお住まいの方々はもちろん、リモートからの参加もお待ちしております。ユーザビリティパネルにご参加頂いた方々には、感謝の気持ちを込めて Amazon.com ギフトカードを贈呈いたします。

参加するには今すぐ登録にアクセスしてください。

Jeff;

Snowball HDFS のインポート

オンプレミスで MapReduce を実行していて、HDFS (Hadoop Distributed File System) にデータを保存している場合、中間のステージングファイルを使用することなく、そのデータを直接 HDFS から AWS Import/Export Snowball にコピーできるようになりました。多くの場合、HDFS はビッグデータワークロードに使用されるため、これにより大量のデータを AWS にインポートしてさらに処理するプロセスが簡略化されます。

この新機能を使用するには、最新バージョンの Snowball クライアントを、目的の HDFS クラスターを実行しているオンプレミスホストにダウンロードして設定します。次に、以下のようなコマンドを使用して、Snowball 経由で HDFS から S3 にファイルをコピーします。

$ snowball cp -n hdfs://HOST:PORT/PATH_TO_FILE_ON_HDFS s3://BUCKET-NAME/DESTINATION-PATH

-r オプションを使用して、フォルダー全体を再帰的にコピーできます。

$ snowball cp -n -r hdfs://HOST:PORT/PATH_TO_FOLDER_ON_HDFS s3://BUCKET_NAME/DESTINATION_PATH

詳細については、「HDFS クライアントの使用」を参照してください。

Jeff;

※AWS Import/Export Snowballは日本で未提供のサービスです。

新しい collectd の CloudWatch プラグイン

これまでご自分のビジネス、アプリケーション、システムメトリックスを Amazon CloudWatch で保存されてきたと思います (詳しくは「Amazon CloudWatch の新しいカスタムメトリックス」をご覧ください)。随分前のことになりますが、私が 2011 年に書いたブログで「ユーザーの AWS リソースを CloudWatch で保存しているように、グラフを表示したり、アラームを設定、自動化したアクションをこうしたメトリックスに基づいて設定することができます。」といったように、この機能についてご紹介したことがあります。

そして本日より、新しい CloudWatch プラグイン collectd 対象を使用することで、ユーザーのシステムから統計を収集する方法を簡略化しながら収集した情報を CloudWatch に保存できるようになりました。さまざまなタイプの統計を収集する collectd の機能と、保存、表示、アラート、警告を可能にする CloudWatch の機能を組み合わせることで、EC2 インスタンスの状態とパフォーマンス、そして EC2 で実行しているオンプレミスハードウェアやアプリケーションについてより細かく把握することができます。このプラグインはオープンソースプロジェクトとしてリリースしています。皆様からのプルリクエストをお待ちしております。

パフォーマンスと可搬性を提供するため collectd デーモンは C で記述されています。これは 100 以上のプラグインをサポートし、ApacheNginx ウェブサーバーパフォーマンス、メモリ使用量稼働時間の統計を収集できるようにします。

インストールと設定
実際のアクションを見るため、collectd と新しいプラグインを EC2 インスタンスにインストールして設定してみました。

まず、CloudWatch にメトリックスデータを書き込むためのアクセス許可を使用して IAM ポリシーを作成します。

次にポリシーで EC2 を許可する IAM ロール (インスタンスで実行する collectd コード) を作成します。

オンプレミスサーバーから統計を収集するためにプラグインを使用する予定の場合や、すでに EC2 インスタンスを実行している場合は、このステップを行わずに適切なアクセス権限を代わりに使用して IAM ユーザーを作成します。私の場合、最初の例ではなくこの方法を実行していたら、ユーザーの認証情報をサーバーまたはインスタンスに追加する必要がありました。

ポリシーとロールの準備ができたら、EC2 インスタンスを起動してロールを選択します。

ログインを完了し collectd をインストールします。

$ sudo yum -y install collectd

次にプラグインを取得しスクリプトをインストールします。スクリプトを実行可能にしたら、それを実行します。

$ chmod a+x setup.py
$ sudo ./setup.py

いくつかの質問に答えた後、問題なく設定を実行できました。collectd は設定完了後に起動しました。

Installing dependencies ... OK
Installing python dependencies ... OK
Copying plugin tar file ... OK
Extracting plugin ... OK
Moving to collectd plugins directory ... OK
Copying CloudWatch plugin include file ... OK

Choose AWS region for published metrics:
  1. Automatic [us-east-1]
  2. Custom
Enter choice [1]: 1

Choose hostname for published metrics:
  1. EC2 instance id [i-057d2ed2260c3e251]
  2. Custom
Enter choice [1]: 1

Choose authentication method:
  1. IAM Role [Collectd_PutMetricData]
  2. IAM User
Enter choice [1]: 1

Choose how to install CloudWatch plugin in collectd:
  1. Do not modify existing collectd configuration
  2. Add plugin to the existing configuration
Enter choice [2]: 2
Plugin configuration written successfully.
Stopping collectd process ... NOT OK
Starting collectd process ... OK
$

collectd を実行することができ、プラグインのインストールと設定が完了したら、次のステップは目的の統計を決定し、CloudWatch に発行するプラグインを設定することです (メトリックスごとに料金が発生するので、これは大切なステップです)。
ファイル /opt/collectd-plugins/cloudwatch/config/blocked_metrics には、収集したメトリックスのリストが含まれていますが、これは CloudWatch に発行されていません。

$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics
# This file is automatically generated - do not modify this file.
# Use this file to find metrics to be added to the whitelist file instead.
cpu-0-cpu-user
cpu-0-cpu-nice
cpu-0-cpu-system
cpu-0-cpu-idle
cpu-0-cpu-wait
cpu-0-cpu-interrupt
cpu-0-cpu-softirq
cpu-0-cpu-steal
interface-lo-if_octets-
interface-lo-if_packets-
interface-lo-if_errors-
interface-eth0-if_octets-
interface-eth0-if_packets-
interface-eth0-if_errors-
memory--memory-used
load--load-
memory--memory-buffered
memory--memory-cached

メモリの消費量が気になっていたので、次のラインを追加しました。 /opt/collectd-plugins/cloudwatch/config/whitelist.conf:

memory--memory-.*

collectd の設定ファイル (/etc/collectd.conf) には collectd とプラグインの設定も含まれています。私の場合、変更の必要はありませんでした。

変更を反映させるため、collectd を再起動させました。

$ sudo service collectd restart

多少のメモリを消費させるためにインスタンスを少し使用してから、CloudWatch コンソールを開きメトリックスを探し表示しました。

このスクリーンショットには、今後 CloudWatch コンソールに施される強化点のプレビューが含まれていますので、ご自分の画面に同じものが表示されなくてもご安心ください (詳しくは今後お知らせします)。

プロダクションインスタンスをモニタリングしていたのであれば、collected プラグインを 1 つ 2 つインストールすることもできました。Amazon Linux AMI で利用可能なリストは次をご覧ください。

$ sudo yum list | grep collectd
collectd.x86_64                        5.4.1-1.11.amzn1               @amzn-main
collectd-amqp.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-apache.x86_64                 5.4.1-1.11.amzn1               amzn-main
collectd-bind.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-curl.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-curl_xml.x86_64               5.4.1-1.11.amzn1               amzn-main
collectd-dbi.x86_64                    5.4.1-1.11.amzn1               amzn-main
collectd-dns.x86_64                    5.4.1-1.11.amzn1               amzn-main
collectd-email.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-generic-jmx.x86_64            5.4.1-1.11.amzn1               amzn-main
collectd-gmond.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-ipmi.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-iptables.x86_64               5.4.1-1.11.amzn1               amzn-main
collectd-ipvs.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-java.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-lvm.x86_64                    5.4.1-1.11.amzn1               amzn-main
collectd-memcachec.x86_64              5.4.1-1.11.amzn1               amzn-main
collectd-mysql.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-netlink.x86_64                5.4.1-1.11.amzn1               amzn-main
collectd-nginx.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-notify_email.x86_64           5.4.1-1.11.amzn1               amzn-main
collectd-postgresql.x86_64             5.4.1-1.11.amzn1               amzn-main
collectd-rrdcached.x86_64              5.4.1-1.11.amzn1               amzn-main
collectd-rrdtool.x86_64                5.4.1-1.11.amzn1               amzn-main
collectd-snmp.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-varnish.x86_64                5.4.1-1.11.amzn1               amzn-main
collectd-web.x86_64                    5.4.1-1.11.amzn1               amzn-main

主要事項
バージョン 5.5 以降の collectd を使用している場合は、4 つのメトリックスがデフォルトで発行されるようなりました。

  • df-root-percent_bytes-used – ディスク速度
  • memory–percent-used – メモリ使用量
  • swap–percent-used – スワップ使用率
  • cpu–percent-active – cpu 使用率

これらを発行したくない場合は whitelist.conf ファイルから削除することができます。

現在、Amazon Linux AMI、Ubuntu、RHEL、CentOS のプライマリリポジトリは古いバージョンの collectd を提供しています。カスタムリポジトリからインストールした場合またはソースから構築した場合はデフォルト設定による動作が異なる点にご注意ください。
その他
ご紹介できるものは他にもあるのですが、残念ながら時間切れです。その他のプラグインもインストールし whitelist.conf を設定してさらに多くのメトリックスを CloudWatch に発行することができます。CloudWatch アラームを作成してカスタムダッシュボードやその他を設定することもできます。

始めるには GitHub の AWS ラボにアクセスし collectd の CloudWatch プラグインをダウンロードしてください。

Jeff;