Author: AWS Japan Staff

週間 AWS – 2016 年 3 月 14 日 先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 14 日 AWS SDK for C++ の開発者プレビューが使用可能になったことを発表しました。 AWS クラウド 10 周年を祝いました。 Sqoop、HCatalog、Java 8 などを含む Amazon EMR 4.4.0 をスタートしました。 AWS コンピューティングブログで、欧州 (フランクフルト) リージョンにおける AWS Lambda および Amazon API Gateway の使用開始を発表しました。 Amazon Simple Email Service ブログで、Amazon SES がドメインからのカスタムメールをサポートするようになったことを発表しました。 AWS Java ブログに、Amazon SQS […]

Redshiftの新しいバージョン1.0.1040リリースについて、その新機能や修正一覧の説明とメンテナンスの予告が公開されています。 Release: Amazon Redshift on 2016-03-17 Announcement: Amazon Redshift improvements and maintenance (Mar 17 – Mar 31) このリリースには以下の新機能が含まれています。 ユーザが定義したしきい値よりも大きい比率でソート済の表は、VACUUMでソートをスキップするように COPYで条件にそったデータを挿入した場合、ソート済の領域としてマージされるように 接続ログに、SSLのバージョンとSSLサイファーが記録されるように 1.はVACUUMコマンドの機能改善です。VACUUMは不要領域の削除とソートという2つの機能を持っているのですが、すでに大半の領域がソート済の場合はソート処理自体をスキップすることでVACUUMに掛かる時間を短縮します。 デフォルトではその閾値は95%に設定されていますが、これはユーザが指定することが可能です。VACUUMコマンドが拡張されTO sort_threshold PERCENTという形で指定できます。この数値を100にした場合は（今までと同様）常にソートが実行されるようになりますし、逆に0にするとソートが行われなくなります。この新しいオプションはREINDEXやDELETE ONLY等とも併用可能です。 参考）VACUUMコマンド　※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。 2. ですが、Redshiftの中では表のデータは「ソート済領域」と「非ソート済領域」に分けて管理されています。VACUUMを使ってソートされたデータはソート済領域に保存され、追加データは非ソート領域に保存されます。 今回の機能拡張では、条件を満たした場合にCOPYで追加したデータがソート済領域に追加されるようになります。その条件はマニュアルの以下のページに記載されています。 Loading Your Data in Sort Key Order　※本エントリ執筆時点ではまだ日本語マニュアルが更新されていませんでした。その場合は英語に切り替えてご覧ください。  条件は以下の通りで、これらを全て満たしている必要があります。 表がコンパウンドソートキー（Interleaved Sort Keyではなく）を使っていて、かつソートキー列が1つのみ ソートキーの列がNOT NULL 表が100%ソート済か、もしくは空（から） 新しく追加されるソートキー列の値が既存データよりソート順で大きい値を持つ これは、列に常に大きい値が挿入されるようなケース、つまり時刻がソートキーになっていて、そこに追加で新しいデータを追加し続けるような表構造（時系列でデータを入れ続ける）の場合に役に立ちます。 3.は記述のままですね。STL_ CONNECTION_LOGにsslversionとsslcipherという列が追加されています。もしこのSTL表を定期的に別表やファイルにエクスポートしている場合は、クラスターバージョンが上がった途端に列が増えるのでご注意ください。 この他に、INリスト指定時にスキャン範囲を限定することで速度を向上させる機能や、クラスターリサイズ時の転送スループット向上（リサイズに掛かる時間の短縮）、Window関数利用時にORDER BY句が必須ではなくなるといった機能向上、およびバグの修正が行われています。 この新しいバージョンはこれから約2週間にかけて各リージョンにデプロイされます。適用されるとクラスターのバージョンが1.0.1040になっているはずです。 なお、すでにオレゴンリージョン(US-WEST-2)にはデプロイされていますので、新規にオレゴンでRedshiftクラスターを立ち上げると1.0.1040で起動できます。すぐに新機能を確認したい方はオレゴンで試してみてください。 下佐粉　昭（@simosako）

AWS IoT のルールでデバイスが生成したデータを直接、 Amazon Elasticsearch ドメインに渡すことができるようになりました。これによってデータを分析したり、データに対してフルテキストやパラメータによる検索を実行したり、 Kibana で可視化したりすることができます。この連携によって、デバイスの特定のエラーコードをフルテキスト検索したり、デバイスのパフォーマンスをリアルタイムに近い形で視覚化するような、ユースケースをサポートします。 加えて、AWS IoT のルールによって、デバイスが生成したデータを Amazon CloudWatch に発行することができるようになりました。これによって、デバイスのメトリックスをグラフ化して見たり、アラートをセットすることができます。 これらの新しいルールをどのように利用するかについての、より詳しい情報については、AWS IoT デベロッパー ドキュメントを参照してください。または、コンソールにサインインして、ルールを試すことができます。   日本語への翻訳は SA福井が担当しました。原文はこちらです： https://aws.amazon.com/jp/about-aws/whats-new/2016/03/aws-iot-integrates-with-elasticsearch-service-and-cloudwatch/  

みなさんは、現在リレーショナルデータをオンプレミスのOracle, SQL Server, MySQL, MariaDB, PostgreSQLといったデータベースに保存されていますか？それらのデータをAWSクラウドに実質的なダウンタイム無しで移動させ、スケールアウト可能というメリット、効率化されたオペレーション、複数のデータストレージが用意されている環境に移行する事に興味はありませんか？ もしそうであれば、新しい AWS Database Migration Service (DMS) こそ、みなさんのためのサービスです！去年の秋に開催されたAWS re:Inventで最初の発表がなされ、すでにお客様により1,000を超えるオンプレミスのデータベースがAWSに移行されています。お客様はテラバイト級のデータベースを動かしたままクラウドに移行する事が可能になります。データベースプラットフォームを変えずに移行することも可能ですし、要件により適切な別のデータベースプラットフォームに移行することも可能です。新しいデータベースプラットフォームへの移行を、システム全体のクラウド移行とともに実施する場合は、AWS Schema Conversion Tool がみなさんのスキーマやストアドプロシージャを新しいプラットフォーム用に変換する事をお手伝いします。 AWS Database Migration ServiceはレプリケーションインスタンスをAWS上にセットアップすることで稼動を開始します。このインスタンスはソースデータベースからデータをアンロードし、ターゲットのデータベースにロードします。これは”on-going replicaion”をサポートしており、ダウンタイムを最小にする形でのマイグレーションをサポートします。加えて、DMSは、データ型変換や異機種間データ移動（例：OracleからAurora）といった多くの煩雑な処理を代行してくれます。このサービスはレプリケーションの状況やインスタンスをモニターしており、なにか発生した場合はユーザに通知するとともに、自動的に代替となるインスタンスをプロビジョンします。 DMSは多様なマイグレーションシナリオおよびネットワーク接続のオプションをサポートしています。１つのエンドポイント（※ソースもしくはターゲットのデータベースサーバ）はAWS上にある必要がありますが、他はオンプレミスでも、EC2上のデータベースでもRDSでもかまいません。ソースとターゲットは両方が同じVirtual Private Cloud (VPC)上にあっても良いですし、別々のVPC上でもかまいません（AWS上で稼動するデータベースを別のVPC上に移すようなケース）。オンプレミスのデータベースに対してもパブリックインターネット経由で接続するか（インターネットVPNを使うことも可能です）、AWS Direct Connectで接続することが可能です。 データベースをマイグレーションする 数クリックでマイグレーションをセットアップすることが可能です！ターゲットデータベースを作成して、データベーススキーマを移行し、データレプリケーションプロセスをセットアップし、最後にマイグレーションを実行するだけです。ターゲットデータベースがソースの内容に完全にキャッチアップできたら、あとは本番環境から利用するデータベースを切り替えるだけです。 AWS Database Migration Service コンソールを選択して、”Create Migration“をクリックします。（AWS Migration Serviceコンソールは、AWSマネジメントコンソールのデータベースのセクションに「DMS」と書かれたアイコンで表示されています）   コンソールにはマイグレーションプロセスのオーバービューが表示されています: Nextをクリックして、レプリケーションインスタンス作成に必要なパラメータを入力します: このブログポストでは、既存のVPCを選択し、”Publicly accessible”のチェックを外しています。同僚の社員が、私のためにEC2上に”オンプレミスDB”役のデータベースをセットアップしてくれているからです（訳注：オンプレミスのサーバと、VPNやDirect Connectを使わずにグローバルIP経由で接続するような場合は、ここでPublic accessibleをオンにする必要があります）: レプリケーションインスタンスが作成されると、ソース、ターゲットの両データベースのエンドポイントを指定し、”Run test“をクリックしてエンドポイントに問題なくアクセスできるかを確認します。（正直に告白すると、テストをパスするために自分のセキュリティグループ設定を何度か修正するることで時間を費やしました） そしてマイグレーションタスクを作成します。Migration typeのところで、”migrate existing data（既存データの一括ロード）”,”migrate and then replicate（一括コピーをした後に、継続的に差分レプリケーション）”,”replicate […]

本日、Amazon Auroraクラスタ中のレプリカノードを昇格させる順番をご指定頂けるようになりました。この機能により、フェイルオーバ発生時のレプリカノードの昇格を扱いやすくなりました。マスターインスタンスに障害などが発生した場合、Amazon RDSは優先順位が高いレプリカノードを昇格させます。低い優先順位を指定することで昇格させたくないレプリカインスタンスをご指定頂けます。例えば、バッチや集計用途などでご利用頂いているレプリカノードに対して低い優先順位を指定することで、昇格を防ぎバッチや集計作業の影響をアプリケーションに与えることを防ぐことも可能です。 フェイルオーバの優先順位は 指定した優先度 優先度が同じレプリカが複数ある場合は、フェイルオーバ発生時のマスターインスタンスよりインスタンスサイズの大きいインスタンス 優先順位もインスタンスサイズも同じ場合は、同じ優先順位のレプリカノードから任意のレプリカノードが選択されます さらに詳細なフェイルオーバのロジックや優先順位についてはAmazon Auroraユーザガイドをご覧ください。Amazon Auroraについてはプロダクト紹介ページをご覧ください。 — 星野 (原文はこちら)

週間 AWS – 2016 年 3 月 7 日 先週 AWS の世界で起こった出来事を振り返ってみましょう。 月曜日 3 月 7 日 AWS CodeCommit 向けの通知をスタートしました。 新規の AWS アカウントがデフォルトで長い EC2 リソース ID に設定されるようになったことを発表しました。 AWS セキュリティブログに、AWS IAM および AWS CloudFormation を使用して VPC へのアクセス制限を自動化する方法を掲載しました。 Botmetric に、AWS セキュリティの脅威に対する取り組みの現状: アクセスコントロールが掲載されました。 CloudCheckr で、AWS の多様なサービスを有効に活用するための 5 つのヒントが共有されました。 CloudEndure に、2016 年に必読のクラウドコンピューティング書籍トップ 5 が掲載されました。 Cloud Academy から、AWS CloudWatch によるログ管理の一元化シリーズのパート […]

  Amazon.comのCTO  Werner Vogelsが、彼のブログでこの10年のAWSの軌跡を振り返っています。ふり返りを日本語でご紹介します。英語のブログ記事はこちらです。 ——————– AWSの革新は2006年3月14日のAmazon S3のローンチで、約10年前の出来事でした。10年前を振り返ると、低価格で予測可能なパフォーマンスにより、セキュアで、信頼性があり、拡張性が高い、構築・運用が実現できていることから、数百もの学びがあります。AWSは、世界規模でサービスを構築・運用できるパイオニアであり、これらの学びは我々のビジネスにとってとても重要です。以前も何度となくお伝えしている通り、経験だけはショートカットするする方法がない、ということです。毎月の数百万ものアクティブなお客様と共に、彼らの先にいる数億ものお客様と共に、お客様にサービスを提供しながら改善するためのまたとない環境と学ぶ機会を得ています。 みなさんと共有したいいくつかの学びをご紹介します。 1. 進化可能な仕組みを構築する ビジネスが始まる初日から、開発していたソフトウェアは、もはやソフトウェアに非ず、ということを一年間走らせてみてわかりました。その期待値は、金額でいえば一桁、二桁も異なり、スケールの問題を解決する為のアーキテクチャの再考が必要になったものです。   とはいえ、世界中で24時間365日多くのシステムが我々のプラットホームで動作しているのですが、システムアップグレード時にメンテナンスによる中断を起こさないようにする形態をとることはできませんでした。我々は、サービス停止を起こさずに新たなコンポーネントを導入できるアーキテクチャを作る必要がありました。Marvin Theimer, Amazon Distinguished Engineerの彼が、Amazon S3を例えば言うならば、当初は単機エンジンだったセスナが、時間を経過するとボーイング737や747sにアップグレードされている、そして最後はエアバス380sのようだ、と冗談まがいに言っていました。成長の途中で、空中燃料補給をしながら、お客様に築かれないように飛行機を乗り換えているようだと。   2. 想定していないことを想定する 失敗はもたらされるもので、すべてが最後は失敗に成り立っている。ルーターからハードディスク、OSからメモリユニット、誤ったTCPパケット、一時的なエラーから、永続的な故障などがあります。これは、最高品質のハードウェアであろうが量産品であろうが、最終的な顛末は同じです。 拡張性において、さらに重要になってきます。例えば、S3が数兆回ものトランザクションを処理しているときでも、ほんのわずかな可能性でも、それは現実に起こります。このような故障のシナリオの多くは事前に予知できますが、設計や構築時点では知る由もありません。 我々は、故障が何なのかは知らずとも、自然発生で起こる故障も冗長化しカバーできる構築が必要でした。システムがもし火事にあったとしても動作し続ける構造が必要なのです。システム全体をダウンさせることなく、個々のモジュールを管理できることが重要です。我々は、システム全体のヘルスチェックを可能にするような、故障発生時の影響範囲を管理する基本的な仕組みを開発しました。   3. フレームワークでなくプリミティブ ほどなくして、AWSのサービスを利用したいと考えている企業の多くは既に何らかのAWSサービスを取り組んでいると気づきました。お客様が制約を許容し、過去のIT関連のハードウェアとデータセンターの世界と決別すると、前例のない使用パターンで構築し始めるということが起こりました。そのように、お客様のニーズに合ったものを確実に届ける為に、素早く動かざるを得ない状況でした。 もっとも重要な事のひとつに、小さなサービスやツールをお客様に届けるという事で、ひとつのフレームワークを強制されるよりも、キッチンの道具のようにすべてそろっていて組み合わせるように、AWSクラウドで実現できる最適な方法を選んでいただけるような構成にしていました。この方法はお客様の成功につながりましたし、後にAWSのサービスの基本的な製品／サービスの考え方をして活用しています。 お客様がサービスを手に取り、使って構築するまで、どのような優先順位で対応すべきか予期することは難しい、ということに気付くのが重要です。最小の機能性でサービスをリリースし、お客様の要望に合わせてサービスのロードマップを作っています。 4. 自動化がカギ サービスを構築するのと従来のソフトウェア開発でお客様に納品するのとは大きく異なります。拡張性の高いシステムを管理するには、お客様の期待する信頼性、パフォーマンス、スケーラビリティに合うようにする異なるマインドセットが必要です。できるだけ自動化を可能にし、マニュアル操作とエラーを事前に取り除く管理方法を実現するには自動化が重要なカギになります。実現するには、操作に重要となる機能を制御するAPIを構築する必要がありました。お客様にも同様に助けになることです。アプリケーションの構造を分解し、それぞれ管理用APIで、拡張可能でパフォーマンスとメンテナンス性に優れたルールを作ることができます。 5. APIは永続 アマゾンの小売りの経験から得たものでもありますが、AWSがAPI中心のビジネスになることはさらに重要です。お客様が我々のAPIを使ったシステムとアプリを構築し始めたのなら、お客様のビジネスに影響を与えるとして、APIを変更することは不可能になります。APIのデザインは非常に重要であり、正しく設計できるチャンスは一度きりだということを肝に銘じねばなりません。 6. リソースの使い方を知る 適切なサービス利用料を特定しサービスを見積もる際には、コストと運用の良いデータを手に入れることです。特に薄利多売のビジネスモデルにおいてです。AWSはコストを低減させるための努力を惜しまないため、お客様に届けるサービスも投資してもよいと思えるものであり、さらに値下げしても運用継続可能な範囲を見極め、利益を低価格という形でお客様に還元しています。 先の一例として、S3ではどの程度使用されるかパターンがわかりませんでした。ですから、ストレージとネットワークの帯域に対して主な課金を行うというように仮定しました。しばらく運用した後、リクエスト回数も同様に重要な指標だと気づきました。もしお客様がたくさんの小さなファイルを持っているとすると、ストレージと帯域は何百万件のリクエストであろうと計算しませんでした。我々は、AWSのビジネスが継続的なものになるよう、計算モデルを調整しなければなりませんでした。 7. ゼロからのセキュリティ対策 お客様をセキュリティの脅威から守ることは、運用の観点においても、提供するツールや仕組みにおいても、AWSとしては最優先すべき事項です。我々が永遠に投資をし続ける領域です。 素早く学ぶひとつのアプローチとして、最初にサービスを企画・設計する段階で、セキュリティ対策を組み込んでおくことが必須です。セキュリティの専門チームは、何かを構築してから検証するチームではありません。サービスが始まるその日からパートナーとして基本的なセキュリティが担保され強固であるか確認しています。セキュリティに関しては妥協しません。 8. 暗号化は最良の住人 暗号化はお客様にとってデータにアクセスする人に対する最大の制御方法であると言えます。10年前、暗号化のツールやサービスは使いにくく、我々のサービスにどう組み込むのがベストか検討しました。 暗号化はコンプライアンス順守の観点で、サーバーサイドの暗号化をS3で実装しました。もしあなたがデータセンターでディスクをのぞき見しようとしても、どのデータへもアクセスはできないでしょう。しかし、Amazon CloudHSMと後のAmazon Key Management Serviceを使えば、お客様は独自キーの管理とそれを使った暗号化ができるようになります。 今では、暗号化対応は新サービスには企画・設計段階で統合されています。例えば、Amazon Redshiftは、それぞれのデータブロックはデフォルトでランダムキーで暗号化され、そのキーの集合はマスターキーで再度暗号化されています。マスターキーはお客様だけが知る唯一のキーで、ビジネスデータまたは個人情報にアクセスするための復号キーとなります。 暗号化は我々のビジネスにとって優先度の高い事項です。お客様にとってより簡単に使える暗号化の手段を継続して提供し、データやお客様をより強固に守ります。 […]

  10年前の今日、simple blog postでAmazon S3のローンチについて発表しました！それから10年経過したとは信じ難いです。そうでなければ、2000ものブログ記事を書いてはいないでしょう。   Future Shock私が高校生の頃、1977年当時新しいと言われていたFuture Shockというタイトルの書籍を読んでレポートを書きました。その本の中で、未来学者のAlvin Tofflerが急速な変化は、人々を圧倒し、ストレスを加え、方向を失わせることについて論じていました。そのレポートをごみ箱に捨てるまでの間、変化はよいことであり、人も組織も受け入れ対処することによってさらによくなる、と議論したのを覚えています。 まだキャリアの浅い頃、多くの予見されている技術は、新しいものに移行するというよりも、過去のものをよりよくしている状況でした。その時、私は21歳で、過去よりも未来の技術の世界でやっていく、変化と進化を受け入れるだけではなく、積極的に探し求める、と決めました。その決断から35年が経ちました。2004年に最初のブログを書き始め、今では10年もの間AWSに関連するニュースをお届けすることができています。 A Decade of IT Change ～ 10年の軌跡、ITの変化10年10年を振り返ってみると、ITの世界がどれだけ変化したのかを目の当たりにし、とても感銘を受けます。さらに印象深いことは、技術の面だけに留まらず、ビジネスモデルやその関連する事も変化しました。そのビジネス面の変化は、手に入れる、消費する、資源に対して支払う方法に新たな手段をもたらしました。エンタープライズやスタートアップの両方で起こっています。我々の使う表現や描写までも変化しているのです！10年前、まさか「クラウド」「マイクロサービス」「サーバレスアプリ」「IoT（モノのインターネット）」「コンテナサービス」「リーンスタートアップ」などという言葉を口にするとは思いませんでした。加えて「継続的インテグレーション」「継続的デリバリ」「DevOps」「ChatOps」を行っているとも思いませんでした。ChatOpsを試したことがないのであれば、VoiceOpsなるさらに新しい技術もあるのでお忘れなく。 むろん、変化をつかまえることは簡単な事ではありません。将来を見たとき、一瞬で終わるものなのか、それとも本物のトレンドなのかを見極めるようになることが必要で、昨日あったたわいもない技術が明日には本流になる技術に、すぐに軸足を変えられる柔軟さも持ち合わせていなければなりません。JavaScriptをその例として用います。（私のような）あなたが、もし、初期のころサーバサイドの開発者としてJaveScriptがあったら気にも留めなかったでしょうし、ブラウザのみで動作する言語は無視したでしょう、あなたは疑いもなくAjaxといった機能豊富で動的なアプリやNode.jsなどサーバ側で動く言語を動作させなかったでしょう。 今日、現状が意味するところは、同じプログラム言語、システムアーキテクチャ、業界のベストプラクティスが存在するということです。それは、現状のスキルを磨くことや新たなものを探すことに日々時間を使ったほうがいいということを意味しています。一日のうちに複数の開発が同時に起こる新しい世界が、グローバルチームと合意・協働し、ビジネス価値を提供し続けて、当たり前の状態になってきます。 A Decade of AWS　～ AWSの10年AWSがローンチしたいくつかのサービスとブログ記事を見てみましょう。 最初でいまだ関連の深いサービス (2006) – Amazon S3 とてもシンプルなコンセプトですが、裏側の仕組みは複雑に動作しています。TechCrunchが革新的だと当時言っていました！ 時間単位のサーバリソース (2006) – Amazon EC2 Cabo San Lucanのプールサイドに座ってブログを書いていました。ローンチは数か月間ひっ迫し、飛行機に乗る直前で世に出ました。そのシンプルなスタート（インスタンスタイプはひとつ、ひとつのリージョン対応、CLIのみでアクセス）から、今ではお客様の声を多数取り入れ現在に至ります。2006年の今日の出来事でした。 データベースを簡単に (2009) – Amazon Relational Database Service (RDS) インストールに時間を使う、チューニングするなどMySQLの管理工数は高く、個人的にも長期的なプロジェクト課題でした。RDSがいかにワークロードを軽くしたか、感謝したいです。 高度なネットワーク (2009) – Amazon Virtual Private Cloud […]

  AWSのVP and Distinguished EngineerであるJames Hamiltonが、彼のブログでこの10年のAWSの軌跡を振り返っています。ふり返りを日本語でご紹介します。英語のブログ記事はこちらです。 ——————–   2006年3月14日はコンピューティングの新時代の始まりでした。それは、Amazon Web ServicesがSimple Storage Service (S3)をリリースした日だからです。技術の点では、Simple Queuing Services (SQS) が先にリリースされましたが、クラウドコンピューティングにおいては、S3が光を点したといえるでしょう。その日をよく覚えています。そのとき私は、Microsoftの子会社となったアンチスパム、アンチマルウェア、アーカイブサービスをクラウドで提供するFrontbridge Technologiesのジェネラルマネージャでした。この経験で、クラウド管理型サービスの顧客価値がわかりました。お客様も設定のスピードが速くコストが低減できるクラウドが好きなことがわかり、多くの経験から既に気持ちが変化していました。クラウドホスティングが今後の本流だと感じたものです。  いまだにS3の発表は私にとって開眼した出来事です。テクノロジ業界は毎日１００もの発表をしていますが、多くを目にすることはありません。多くの場合、興味がわくようなものではないのです。でも、S3の発表は革新的でした。特に驚いたのはサービスの価格でした。我々が当時支払っていたデータセンターの冗長ストレージの２桁近く安い価格だったのです。でも、さらなる破壊的な事もあり、サービスを利用するにはクレジットカードのみ登録すればよいという事でした。経理の承認の裁可もいらないし、相見積を取る必要もなく、ベンダーを選ぶ必要もなく、ベンダーとの交渉も必要なく、データセンターのスペースを探す必要もありませんでした。ただ、サインアップして使い始めることができたのです。 注目すべきことは、低価格と設定の容易さで、いわゆるトラディショナルなエンタープライズのITプレイヤーではなく、あのAmazonから発表があったという事なのです。高い中間マージンが必要で、交渉が難しく、ライセンス使用の監査も必要な企業ではなく、あのAmazonなのです。多くの企業においては、中間マージンが得られなければ、経営層を変えろという話になるでしょう。Amazonのビジネスは大きな変化をもたらしました。異なるサプライヤ、異なるビジネスモデル、設定にかかる短いステップ、そして徐々に安くなるのではなく、最初から価格が圧倒的に低いという、根本的に異なる価格体系です。 S3の発表は業界横断的に興味をそそり、どうやったらそれが可能になるのだろうかと疑問の声がありました。大量に仕入れと供給をするサプライヤであっても、バイト単位の販売に関しては実施しないでしょう。本当にその内容がいいと思いましたし、信頼できるストレージシステムとして、S3を使って作成したソースコードを保存していました。その時は、すこし格好悪いですが、とがっていて、大きなことを始めたいという気持ちでアプリを書いていました。 アプリを書いてから動かすまで何日かかかり、デバッグとテストを延長し、月末になって、私はVisaの請求を受け取りました。もちろん、S3が非常に低コストである事は知っていましたが、すべてのアプリ開発とテストにかかった費用は3.08ドルでした。請求が間違えているのかと思いました。開発が終わっても、テストデータはS3に保存してあったのですが、次の月に受け取った請求は0.07ドルでした。 とても革新的でしたし、当時社内でもブログを書きました。CTOやCEOといった会社のリーダーにもデモをしました。プレゼンにはS3での早期の開発例のひとつであるAl Vermeulenの写真が含まれていて、どうS3が動作するか、本当に他と異なるところを強調しました。私は2つのAWSのサービスに対する請求がありました。ポイントはAmazonがただ演技や少し試してみるといったことで一時的にサービスを提供しているわけではなく、インフラサービスの提供の真に新たな方法であると本当に考えられたものでした。当時は、ストレージが最初のリリースで、その後まもなくコンピューティングのサービスが始まりました。 私は心底AWSに興味を持ち、2007年までユーザグループのミーティングにも参加していました。Amazonでプレゼンも実施し、最終的には2008年後半にAmazonに入社しました。 AWSのエンジニアチームのメンバーとなりましたが、私の第一印象はとてもスピードが速いと、言い表せるのではないでしょうか。他の会社では、決定は素早くなされ新たなアイデアはソースコードになったとしても、最終的にお客様が利用できるようになるには大陸移動と同じくらい時間がかかる、いわゆるエンタープライズITのペースになります。前職では、半分冗談で「我々はお客様が必要かどうか10年に2度リリースすればよい」と考えていました。AWSでは、機能はすぐにリリースされ、追えないくらいになっています。 他に面白いストーリーとしては、エンジニアチームの議論をどうまとめるかです。議論はしばしば起こり、積極的なディベートになります。決定事項はさらなる情熱や信念が加わりますが、最終的にはデータに基づいた判断がなされます。AWSでは、戦略とお客様が何を必要としているのかの代わりに、我々が便利と思うものを見つけリリースし、広くお客様へのサービスとして普及するかどうか見極めてから投資をします。よいサービスが最高のサービスに素早く育つわけです。 以前の役割の中のいくつかで、このような建設的な議論が生活よりも多くを占め、ここ数年間の非生産性に終止符を打ちます。AWSならお客様の使用データからデータを発見し、素早くアクションにつなげられます。ディベートから成果物ではなく、その逆もあります。多くの労力をお客様が判断します。このような労力からソリューションが提供できるようになるのです。成果物のスピードはお客様が使うことでさらによくなることから、AWSはエンジニアにとってはエキサイティングな環境です。 イノベーションの証明となるのはお客様のコミットメントで、偽りなく、お客様のコミットメントの表れが全社の取り組みを変えます。Netflixは100%の移行を公で決めた最初の企業です。 2010 Netflix 2013 Kempinski Hotels 2013 Suncorp Group 2014 Infor 2014 Nippon Express 2014 Notre Dame University 2014 National Democratic Institute 2015 The Guardian Media […]

Amazon GameLiftは、クラウドでセッションベースのマルチプレイヤーゲームサーバを簡単かつ費用対効果が高いデプロイ、運用、スケールが行えるフルマネージドサービスです。GameLiftは北米の2つのリージョンで一ヶ月前にローンチされ、本日、日本（ ​​gamelift.ap-northeast-1.amazonaws.com ）とヨーロッパ（ gamelift.eu-west-1.amazonaws.com ）のプレイヤーのために最適なゲームパフォーマンスを提供できるようになりました。   Amazon GameLiftの新しい高度なAuto Scaling機能を利用すると、動的にサーバーFleetのキャパシティを管理するためにGameLiftを設定できます。この機能を使用すると、プレイヤーが高速な接続を確保しがらコストを抑え、サーバのキャパシティをゲームの需要曲線に密接に従うことができます。FleetのためにAutoScaling機能を設定するには、単純にトリガーするタイミングとアクションの種類を定義するポリシーを設定します。例えば、Auto Scalingのルールを「15分以上のアイドル状態のインスタンスが20あれば、10までスケールダウンさせる」といったことができます。GameLift AWS Consoleは、スケーリングのポリシーを作成および適用するためのツールを提供し、またAWS CLIまたはGameLift SDKも使用することができます。Auto Scalingの状態はGameLift AWS Consoleのパフォーマンス・メトリックまたは、Fleetのイベントログで追跡することができます。GameLiftのAuto Scaling機能は、堅牢なAWS Auto Scaling serviceを使用しています。   GameLift Auto Scalingの詳細についてはGameDevのブログの記事をご覧ください。 こちらから始められます。 サービスコンソール ドキュメンテーション FAQ   翻訳はSA 森が担当しました。翻訳元：GameLift Expands Game Server Availability to Europe and Asia and Adds Auto-Scaling