Amazon Web Services ブログ

AWS Japan Staff

Author: AWS Japan Staff

新しいAWSコンピテンシー – AWS移行

お客様から大規模ワークロードをAWS上に移行したい、そしてクラウド移行戦略に関する助言を求めている、とますます聞くようになりました。私たちは、AWS Database Migration Serviceを含むいくつかのクラウド移行ツールやサービス、そしてAWS Professional Services Cloud Adoption Frameworkのようなリソースを提供しています。さらに、AWSへの移行を成功に導く支援に関する専門性を発揮している、AWS Partner Network(APN)のコンサルティングおよびテクノロジーパートナーによる強力かつ成熟したエコシステムがあります。 移行を成功させた実績があり技術力を発揮してきたAPNパートナーをお客様が容易に見分けられるよう、AWS移行コンピテンシー(AWS Migration Competency)のローンチについて発表できることを嬉しく思います。 新しい移行コンピテンシー – 移行パートナーソリューション 移行コンピテンシーパートナーは、複雑な移行プロジェクトの調査、計画、移行、運用といったすべてのフェーズを通じて培ったAWSへの移行を成功させるための豊富な経験を持っており、ソリューションを提供します。 AWS Partner Competency Programでは、 以下のパートナーがエンタープライズ顧客のアプリケーションやレガシーなインフラストラクチャをAWS上に移行する支援ができることを確認しています。 カテゴリーとローンチパートナー 移行デリバリーパートナー – プロフェッショナルサービスによる教育、ツール、人員を提供することで成果を加速させ、すべての移行ステージでお客様を支援します。これらのパートナーは、AWS上のワークロードを継続的にサポートすることができるManaged Service Provider(MSP)としてAWSの監査を受けている関係にもあります。以下がローンチパートナーです(abc順、敬称略): 2nd Watch Accenture Classmethod, Inc. (クラスメソッド株式会社) ClearScale Cloud Technology Partners cloudpack (アイレット株式会社cloudpack事業部) Cloudreach Cognizant Technology Solutions CorpInfo CSC FPT Software Infosys Logicworks REAN Cloud Serverworks (株式会社サーバーワークス) Slalom Consulting Smartronix 移行コンサルティングパートナー – 特定の機能の迅速な開発や特定の成果を達成するためのトレーニングと専門知識を提供します。ソリューションの実装やアプリケーションのモダナイゼーションにおいて、DevOpsの適用を可能にするコンサルティングサービスを提供します。以下がローンチパートナーです(abc順、敬称略): […]

Read More

AWS CodePipeline に OpeWorks とのインテグレーション機能が追加されました

AWS Pipeline のソフトウェア リリース パイプライン内で AWS OpsWorks をデプロイメント プロバイダとしてモデル化できるようになりました。更新されたアプリケーション コードのリリースと OpsWorks 内で実行されるアプリケーションとインスタンスのための Chef クックブックのリリースが自動化できます。 AWS OpsWorks は Chef を利用してアプリケーションのすべての形式とサイズに対する構成と運用を支援する構成管理サービスです。これによってアプリケーションのアーキテクチャ及びパッケージのインストール、ソフトウェアの構成、ストレージのようなリソースを含む個々のコンポーネントの仕様を定義することができます。 この機能は、CodePipeline コンソール、AWS CLI、または AWS SDKとAPI によって使い始めることができます。デプロイメント プロバイダとして OpsWorks を利用するパイプラインを作成する方法を学ぶには、こちらを参照してください。   CodePipeline のより詳細な情報は下記をご参照ください:   製品ページ ドキュメント 製品インテグレーション   (日本語訳はSA 福井 厚が担当しました。原文は以下にあります) https://aws.amazon.com/jp/about-aws/whats-new/2016/06/aws-codepipeline-adds-integration-with-aws-opsworks/

Read More

Amazon EMR 4.7.0 – Apache TezとPhoenix, 既存アプリのアップデート

Amazon EMRを使えば素早くコスト効率よく大量のデータを処理することができます。2009年のローンチ以来、数多くの新機能と増え続けるHadoopエコシステムのアプリケーション達のサポートを追加してきました。以下は今年に入ってから追加したもののうちのいくつかになります。 4月 – Apache HBase 1.2のサポート(EMR4.6) 3月 – Sqoop、HCatalog、Java 8、他のサポート (EMR 4.4) 2月 – EBSボリューム、M4インスタンス、C4インスタンスのサポート 1月 – Apache Sparkのサポートと他のアプリケーションの更新 本日またさらに一歩進めて、Apache Tez (データフロー駆動なデータ処理タスクの協調)とApache Phoenix (OLTPや業務分析のための高速なSQL)を新たにサポートし、合わせて既存のいくつかのアプリを更新しました。これらの新規や更新されたアプリケーションを使うためには、Amazon EMRのリリース4.7.0でクラスタを起動する必要があります。 新規 – Apache Tez (0.8.3) TezはApache Hadoop YARN上で動きます。Tezはデータフローを定義するためのAPIを提供し、それによってデータ処理タスクのDAG (有向非巡回グラフ)を定義することができます。TezはHadoop MapReduceより高速になり得て、HiveとPigの両方と一緒に使うことができます。より詳しくは、EMRリリースガイドをご覧下さい。Tez UIにはDAGの可視化も含まれています: UIは各DAGの詳細な情報も表示できます。 新規 – Apache Phoenix (4.7.0) PhoenixはデータストアとしてHBase (Hadoopエコシステムのメンバーの1人)を使います。PhoenixにはJDBCドライバを使って、同じクラスタや他のクラスタ上で実行されているアプリケーションから接続可能です。いずれの方法でも、高速で低レイテンシで完全なACIDトランザクション機能をもったSQLでアクセスすることができます。SQLクエリはHBaseスキャンの手順にコンパイルされ、並列でスキャンし、各々の結果を集約することで結果セットを生成します。より詳しくはPhoenix Quick Start GuideやApache Phoenix Overviewのプレゼンテーションをご覧下さい。 アプリケーションの更新 また、以下のアプリケーションを更新しています: HBase 1.2.1 – […]

Read More

Amazon RDSでMariaDB 10.1をサポートしました

本日から、MariaDB version 10.1をAmazon RDSでご利用頂けるようになりました。既存のAmazon RDS for MariaDBをコンソールやAPIからバージョンを10.0から10.1にアップグレード可能です。 オープンソースMariaDBデータベースをAmazon RDSで2015/10からサポートを開始してから、多くのお客様がRDSの簡単にセットアップや運用が出来、MariaDBをクラウドでスケール出来る利点をご利用頂いています。 MariaDB 10.1は最新のメジャーバージョンで、パフォーマンス改善やスケーラビリティに関連する多くの改善が実装されています。MariaDB 10.1の特徴的な機能は: XtraDB/InnoDB page compression XtraDB/InnoDB data scrubbing XtraDB/InnoDB defragmentation Optimistic in-order parallel replication ORDER BY optimization WebScale SQL patches Amazon RDS for MariaDB 10.1はAWSの全てのリージョンでご利用頂けます。Amazon RDS for MariaDBの詳細についてはRDSのドキュメントを参照して下さい。 翻訳は星野が担当しました。原文はこちら

Read More

Amazon AuroraでCross-Region Read Replicaがご利用頂けるようになりました

Amazon Auroraクラスタににリードレプリカを追加することでリードキャパシティの増強を行って頂けます。本日、リードレプリカを他のリージョンに作成頂ける機能をリリースしました。この機能を利用することでリージョン間でディザスタリカバリ構成を利用出来、リードキャパシティを拡張出来ます。その他にも、他のリージョンにデータベースをマイグレーションしたり、新しい環境を構築する際にもご利用頂けます。 リードレプリカを他のリージョンに作成すると、Auroraクラスタがそのリージョンに作成されます。Auroraクラスタには15台までリージョン内であればレプリカラグのとても低いリードレプリカを作成出来ます(多くのケースで20ms以内)。リージョン間の場合、ソースクラスタとターゲットクラスタの間の距離に応じてレイテンシが増加します。この構成は、現在のAuroraクラスタを複製したり、ディザスタリカバリ目的でリードレプリカをリージョン間で構成することに利用頂けます。リージョン障害が万が一発生した場合、クロスリージョンレプリカをマスターとして昇格します。こうすることで、ダウンタイムを最小限にすることが可能です。こちらの機能は、暗号化されていないAuroraクラスタに適用可能です。 リードレプリカを作成する前に、ターゲットとなるリージョンにVPCやDatabase Subnet Groupsが存在しているか、マスターでバイナリログが有効になっているかを確認する必要があります。(訳者注: 設定を有効にする前に最新のパッチを適用して下さい) VPCの設定 AuroraはVPC内で起動するため、ターゲットとなるリージョンに適切に設定されたDatabase Subnet Groupsが存在するか確認します: バイナリログを有効にする クロスリージョンレプリケーションを設定する前にバイナリログを有効にする必要があります。もしdefaultパラメータグループをお使いの場合、新しいDB Cluster Parameter Groupを作成します: バイナリログを有効にし(binlog_formatをMIXEDに)、Save Changesをクリックします: 次に、設定を変更するDBインスタンスを選択しModifyを選択します。そして、新しいDB Cluster Parameter Groupを選択しApply Immediatelyを選択してContinueをクリックします。変更を確認し、設定を反映させるためにをクリックします: インスタンスを選択し、再起動を実行しreadyになるまで待ちます リードレプリカの作成 事前準備が完了したら、リードレプリカを作成します!AWS Management Consoleから、ソースクラスタを選択し、 Instance ActionsメニューからCreate Cross Region Read Replicaを選択します: 新しインスタンスやクラスタの名前を設定し、ターゲットリージョンを選択します。DB Subnet Groupを選択し、他のオプションも希望の設定にし最後にCreateをクリックします: Auroraがクラスタやインスタンスを作成します。インスタンスが作成されデータがレプリケーションされるまでcreatingステータスになります(作成完了までの時間はソースクラスタに保存されているデータサイズに依存します)。 こちらの機能は本日からご利用頂けます! — Jeff (翻訳は星野が担当しました。原文はこちら)

Read More

Amazon ElastiCache アップデート – RedisのSnapshotをAmazon S3へエクスポートする事が可能になりました

Amazon ElastiCache はポピュラーなインメモリキャッシュエンジンであるMemcachedとRedisをサポートしています。 Memcachedは低速なディスクベースのデータベース等の結果を高速にキャッシュする事ができ、Redisは永続的にデータを保存できるデータストアとして高速に動作します。Redisはレプリケーションやフェイルオーバなどをサポートすることでの高可用性の確保と、複雑なデータ構造での保存を標準サポートしています。   本日Redisユーザのみなさんに、非常に興味深く、注目すべき新しい機能をリリースしました。まず、実行されているRedis キャッシュクラスタのスナップショットを作成する事は既に可能です。スナップショットは永続的なバックアップや、新しいキャッシュクラスタを作成するために使用することができます。おさらいとしてキャッシュクラスタのスナップショットを作成する方法は次のとおりです: RedisスナップショットがS3バケットへとエクスポートできるようになりました。S3バケットはスナップショットと同一リージョンに存在し、ElastiCacheに適切なIAMの権限(List、Upload/Delete、View 権限)を付与する必要があります。この機能はいくつかの用途を想定しています:   ディザスタリカバリ – スナップショットを他の場所にコピーし保管する 分析 – S3上のスナップショットのデータから使用状況等を分析する 種データ配布 – 別のリージョンにスナップショットを元にした新しいRedisキャッシュクラスタを構築する スナップショットのエクスポート スナップショットをエクスポートするのは簡単です、スナップショットを選択し、Copy Snapshot をクリックしてください: バケットのアクセス許可を確認してください。(詳細はExporting Your Snapshotを参照ください): 次に、新しくエクスポートするスナップショット名と希望する保存先のS3バケット名を入力してください: ElastiCache はスナップショットをエクスポートし、指定したS3バケットにスナップショットを置きます: ファイルは標準のRedisのRDBファイルとして保存され、使用することができます。 また、アプリケーション等のコードや、コマンドラインからも同様の作業を実行することができます。対象のS3バケットを指定し、プログラムコードから呼び出す場合はCopySnapshot、コマンドラインからはcopy-snapshotコマンドを使用してください。 この機能は既に利用可能で、本日から使い始めることができます!エクスポートには料金はかからず、通常のS3ストレージ料金だけで使うことができます。 — Jeff; 翻訳はSA桑野(@kuwa_tw)が担当しました。原文はこちら。    

Read More

Amazon RDS for Oracleで拡張モニタリングがご利用頂けるようになりました

Amazon RDS for Oracleにて、拡張モニタリングがご利用頂けるようになりました。拡張モニタリングでは、DBインスタンスの56種類のシステムメトリクスやプロセスメトリクスを確認頂けます。 拡張モニタリングは既に、 MySQL, MariaDB, Amazon Aurora, PostgreSQL, SQL Serverでご利用頂けていました。本日から、全ての RDS for Oracleインスタンスでご利用可能になりました。拡張モニタリングはAmazon RDSインスタンスの状態をリアルに詳細に確認していただけます。インスタンスのプロセス情報をまとめ、56種類のシステムメトリクスを1秒単位で取得出来ます。RDSコンソールでメトリクスをビジュアライズ出来ますし、Amazon CloudWatchやサードパーティアプリケーションともインテグレーション可能です。 利用可能なメトリクスの全てのリストや詳細なAmazon CloudWatchとの連携に関する情報は拡張モニタリングドキュメントページをご覧ください。RDSインスタンスのモニタリングのために、拡張モニタリングをシームレスにサードパーティアプリケーションと連携するための詳細情報はAmazon CloudWatchドキュメントをご覧ください。 拡張モニタリングは t1.micro及びm1.smallを除く全てのRDS for Oracleインスタンスでご利用頂けます。拡張モニタリングを有効にすると、CloudWatch Logsの料金が課金されます。利用料金に関する詳細はCloudWatch Logs pricingページをご覧ください。 Amazon RDS for Oraclの拡張モニタリングは本日から、 US East (Northern Virginia), US West (Northern California), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Seoul), […]

Read More

EC2インスタンスのコンソールスクリーンショット

ユーザーがAmazon EC2を使用するために既存のマシンイメージをクラウドに移行するとき、ドライバや起動パラメータ、システム構成、そして進行中のソフトウェアアップデートなどによる問題に出くわすことがあります。これらの問題によってインスタンスにRDP(Windowsの場合)やSSH(Linuxの場合)経由で接続できなくなり問題判別を難しくします。従来のシステムでは、物理コンソールでログメッセージや何が起きているのかを特定して理解するための手がかりが見つかることがあります。 インスタンスの状態をより可視化しやすくするために、インスタンスコンソールのスクリーンショットを生成してキャプチャできる機能を提供します。インスタンスが稼働中またはクラッシュした後にスクリーンショットを生成することができます。 こちらがコンソールからスクリーンショットを生成する方法です(インスタンスはHVM仮想化を使用している必要があります): そしてこちらがその結果です: Windowsインスタンスでも使用することができます: CLI (aws ec2 get-console-screenshot)またはEC2 API(GetConsoleScreenshot)を使用してスクリーンショットを作成することもできます。 いますぐ利用可能 この機能は本日から米国東部(北バージニア)、米国西部(オレゴン)、米国西部(北カルフォルニア)、ヨーロッパ(アイルランド)、ヨーロッパ(フランクフルト)、アジアパシフィック(東京)、アジアパシフィック(シンガポール)、アジアパシフィック(シドニー)、そして南アメリカ(ブラジル)リージョンで利用可能です。これに関連する追加コストはありません。 — Jeff; 翻訳はSA渡邉(@gentaw0)が担当しました。原文はこちら。  

Read More

Amazon Elastic TranscoderでMPEG-DASHをサポートしました

Amazon Elastic Transcoderはビデオやオーディオといったメディアファイルを元の形式から他の形式にコンバート可能なサービスです。このサービスはロバスト、スケーラブルでコスト効果が高く簡単にご利用頂けます。ご利用頂くにはpipeline(処理で使用するインプットとアウトプットのS3バケットのペアを指定します)を作成し、トランスコードのjobを作成します。それぞれのjobはインプットバケットから処理対象のファイルを読み込み、jobで指定されたフォーマットへトランスコードを行いアウトプットバケットへ書き込みます。トランスコード(Standard Definition (SD) video, High Definition (HD) video, audio)に応じて課金を行います。トランスコードプリセット(アウトプットフォーマットとそれに関連する設定の集合)をご提供しています。お客様のご要望やエンコード技術の変化に応じて新しいプリセットやフォーマットを追加してきました。例えば、先日VP9 Codecをサポートしました。 MPEG-DASHサポート 本日、MPEG-DASH フォーマットのサポートを開始しました。このフォーマットは、HTTPサーバを用いて高画質・高音質のストリーミングをサポートします。また、アダプティブストリーミングの技術を用いて、ネットワークスループットの状況に応じてビットレートを変えて配信可能です。この技術は様々なデバイスやビットレート環境に適しており、トランスコードプロセスを簡素化し、様々なフォーマットを作成することを避けることが出来ます。 MPEG-DASHのトランスコードプロセス中に、コンテンツは様々なビットレートのセグメンとにトランスコードされ、それぞれの出力を参照するためのプレイリストが作成されます。クライアントは最初にプレイリストをダウンロードします。その後、ネットワーク帯域やレイテンシを監視し、必要なビデオセグメントを要求します。再生中にネットワーク状況が変化した場合、プレイヤは状況に応じて、ビットレートの高い(低い)セグメントを要求します。 トランスコード済みのコンテンツはS3から直接配信することも出来ますし、Amazon CloudFrontを使用して、ユーザに最も近い場所から配信することも可能です。どちらの場合でも、以下の様なCORSポリシーを作成する必要があります。 <?xml version=”1.0″ encoding=”UTF-8″?> <CORSConfiguration xmlns=”http://s3.amazonaws.com/doc/2006-03-01/”> <CORSRule> <AllowedOrigin>*</AllowedOrigin> <AllowedMethod>GET</AllowedMethod> <MaxAgeSeconds>3000</MaxAgeSeconds> <AllowedHeader>*</AllowedHeader> </CORSRule> </CORSConfiguration> CloudFrontを利用する場合は、OPTIONSメソッドを有効にして、キャッシュされることを許可します 加えて、3つのヘッダをディストリビューションのwhitelistに追加します MPEG-DASHでトランスコード MPEG-DASHでアダプティブビットレート機能を利用する場合、1つのトランスコードjobで別々のプリセットを利用して複数のアウトプットを作成します。これらのプリセットを選んで頂けます(ビデオ向けに4つ、オーディオ向けに1つ) このフォーマットを利用する際、適切なセグメントデュレーション(秒)を選択します。短いデュレーションを設定すると多くの小さいセグメントを生成し、クライアントが回線状況の変化により高速に適応出来ます。 全てのビットレートを含んだ、1つのプレイリストを作成するか、みなさまの多くのお客様やコンテンツに適した特定のビットレートを選択可能です。また、ご自身のプリセットを既存のプリセットを元に作成出来ます。 すぐにご利用頂けます MPEG-DASHサポートは本日から、Amazon Elastic Transcoderをご利用頂ける全てのリージョンでご利用頂けます。こちらのフォーマットを利用するための追加料金は必要ありません。料金の詳細は Elastic Transcoder Pricingをご覧ください。 — Jeff (翻訳は星野が担当しました。原文はこちら)

Read More

Amazon ECSでAuto Scaling

Amazon EC2 Container Service (Amazon ECS)のClusterを自動的にスケールさせる方法はありましたが、本日Auto ScalingとAmazon CloudWatchのAlarmに追加された新機能により、ECSのServiceにScaling Policyを利用することができます。ServiceのAuto Scalingにより、需要が高まった時にスケールアウトさせて高い可用性を実現したり、需要が下がったらServiceとClusterをスケールインさせることでコストを最適化するのを、全て自動でリアルタイムに行うことができます。 この記事では、Clusterを需要に合わせて自動的にリサイズさせつつ、この新しい機能がどうやって利用できるかをお見せします。 Service Auto Scalingの概要 すぐに利用できるECS Serviceのスケーリング機能はずっと一番要望を受けていて、ついに今日この機能をアナウンスでき嬉しいです。自動でスケールするServiceの作成手順はとても簡単で、ECSコンソールやCLI、SDKでもサポートされています。希望するTaskの数とその最小・最大数を選択し、1つ以上のScaling Policyを作成すると、後はService Auto Scalingが面倒を見てくれます。Service SchedulerはAvailability Zoneを意識してくれるので、ECSのTaskを複数のZoneに渡って分散するように心配する必要もありません。 それに加えて、ECS Taskを複数AZ Cluster上で実行することも非常に簡単です。ECS ClusterのAuto Scaling Groupが、複数Zoneに渡る可用性を管理してくれるので、必要とされる回復力や信頼性を持つことができ、ECSがTaskのZone間の分散を管理してくれるので、皆さんはビジネスロジックに集中することができます。 利点: 来ているアプリケーションの負荷にキャパシティを対応させる: ECS ServiceとECS ClusterのAuto Scaling Groupを両方にScaling Policyを使います。必要に応じて、Cluster InstanceとService Taskをスケールアウトさせ、需要が落ち着いたら安全にスケールインさせることで、キャパシティの推測ゲームから抜け出せます。これによって、ロングランな環境で低コストな高可用性を実現できます。 複数AZのClusterでECSの基盤に高い可用性を持たせる: Zone障害という可能性から守ることができます。Availability Zoneを考慮しているECS SchedulerはCluster上のTaskを管理し、スケールし、分散してくれるので、アーキテクチャは高い可用性を持ちます。 Service Auto Scalingのデモ この記事では、これらの機能を使い真にスケーラブルで高い可用性を持ったMicroservicesアーキテクチャを作成する手順を辿りたいと思います。このゴールに到達するために、以下の様な手順をお見せします: Auto Scaling Groupで2つ以上のZoneにECS Clusterを作成する。 そのCluster上にECS Serviceを設定し、希望するTaskの数を定義する。 ECS Serviceの前段にElastic Load Balancingのロードバランサを設定する。これが負荷の入り口になります。 […]

Read More