Amazon Web Services ブログ

【読み解くシリーズ】 Amazon Web Servicesが成長する３つの理由

by Tatsuji Ishibashi | on 25 MAR 2016 | in 読み解くシリーズ | Permalink

こんにちは。プロダクトマーケティングマネージャーの石橋です。

2016年は、Amazon Web Services（以下、AWS）が2006年に事業を開始してから10年、2011年に東京リージョンを開設して5年と、節目の年を迎えました。当時はクラウドのパイオニア、今ではある意味老舗になってきたAWSです。特に、ここ数年で多くの企業においてクラウドの活用が進んでいることをニュース等で目にするようになりました。同時に、AWSも多くのお客様にご利用いただけるようになりました。なぜ、AWSは成長し続けているのでしょうか？理由を考えてみたいと思います。

■10年前のクラウド、今のクラウド

クラウドと言えば、システム構築のためのITリソースであるサーバやストレージ機器を、自社や個人で購入、所有することなくインターネット経由で提供し、必要な時に使った分だけ支払う従量課金や、ものの数分でITリソースを準備できる俊敏性が利点のビジネスモデルとして注目されました。AWS設立当時は、いかに早くビジネスを立ち上げ、その結果から次の打ち手を考えることができるかという利点が活かせる、スタートアップ企業を中心にご利用いただいていました。ここ数年は、以前とどう変化したのでしょうか？導入するお客様の業種や事業内容、企業規模は多岐に渡り、お客様の求めるサービスやセキュリティレベル、堅牢性や可用性のニーズに合わせたサービスを提供できるようになりました。AWSクラウドのセキュリティコンプライアンスへの準拠（第三者認証や監査）、専用線によるAWSクラウドへの接続、無料かつ自動更新のSSL証明書（US East（Northern Virginia）リージョンのみで提供）※など、企業においてクラウドにおけるガバナンスが効くようになり、利用している企業だけでなく、さらにその先のお客様が安心してサービスを利用できるようになりました。また、お客様と共にサービスを拡充し続けることで、多種多様な企業においてご利用いただけるようになりました。

■クラウドによるビジネスモデル変革

導入が進むクラウドですが、AWSが最初に起こしたビジネスモデルの変革は何でしょうか？それは「ITリソースの購買体験を大きく変えたこと」です。必要な時に使った分だけ、事前の契約なしに、誰でも購入できる体験です。従来のITリソースの購買（調達）体験をシステム導入のライフサイクルから考えてみましょう。システム開発のライフサイクルには、ビジネス要件の定義、インフラ設計、システム設計（サーバサイジング設計や容量計画）、ソフトウェア設計、ソフトウェア開発、運用管理設計、システムテスト、システム運用（メンテナンス）、End of Service(EOS)と一連の流れがあります。この中で、AWSのクラウドで費用・人的労力・時間を軽減したり短くする（＝どこか別のところに任せる、考える時間を少なくする）ことができる部分はどこでしょうか？すべての開発サイクルでクラウドにワークロードを移行できます。

■クラウドがビジネスにもたらす利点

ワークロードを移行した結果、ビジネス上の利点は何でしょうか？今までオンプレミス環境を構築している場合、ITシステム構築のワークロードは自社内にありました。これらのITワークロードをクラウド側で処理できるとすれば、システムの導入初期費用だけでなく、中長期にわたり運用する為の人的工数、ハードウェア・ソフトウェアのライセンスやメンテナンス費用まで含めたTCO削減につながります。そして重要なのは、ITワークロードをオフセットしたことによる調達や作業「時間」を、今まで手が付けられなかったことや新たな事業に投資することで、さらなる事業展開の可能性を創出できるようになることです。仕事の仕方が変わるという事なのです。

■AWSが成長し続ける3つの理由

AWSはテクノロジーの変化に合わせて、お客様のビジネス形態も変化していることをいち早く捉え、ビジネスのパートナーとして共に成長しています。AWSの成長はお客様の変革によってもたらされています。それでは、AWSが成長し続ける理由を見てみましょう。

(1) お客様が事業に集中できる

企業や組織内の事業基盤にある技術インフラをAWSにすることで、お客様を差別化するための事業に集中できる状況を作っています。そして長期間に渡って競争力を維持し続ける為の支援を、AWSおよびパートナーエコシステムを活用し一緒にビジネスを行っています。

(2) イノベーションを起こすためのインフラ提供

すべての企業は生き残るためにビジネスや顧客体験を変えていく必要があります。コストの低減は守りの一要素ですが、その先にはビジネスの俊敏性や変革が必要です。そのためのインフラも俊敏、柔軟で革新的であるものを提供し続けています。

(3) ITに必要なモノをあらかじめそろえておく

企業内で使うITリソースは多岐にわたります。必要なモノはできるだけAWSで準備し組み合わせて使うことで、ビジネスのニーズに合わせたアウトプットを、より早く、より簡単に提供できるようになります。2015年は722ものサービスリリースや機能改善を行いました。お客様に、その継続的な進化や革新による利点をすぐに享受していただけます。

クラウドサービスの検討をはじめた方は、どこから手を付けていいかわからない方もいらっしゃると思います。弊社のホームページでセミナー情報を探していただくと、「はじめてのアマゾンウェブサービス」や「初級トレーニング」といった無料でAWSを知る機会がありますので、是非活用してみてくださいね。すぐにでも始めてみたい方は、AWS にサインアップした日から 12カ月間お使いいただける無料利用枠があります。ほとんどの製品をお試しいただけます。ユーザ登録は簡単ですので試してみてください。

AWSアカウントの作成手順はこちら
http://aws.amazon.com/jp/register-flow/

※サービスを提供しているリージョンは3/25現在の情報に基づいています。

Amazon RDS for SQL Server – Windows認証のサポート

by AWS Japan Staff | on 24 MAR 2016 | in Amazon RDS | Permalink

このブログの常連読者の方は私がAmazon Relational Database Service (RDS)の大ファンであることをご存じだと思います。マネージド型のデータベースサービスとして、リレーショナルデータベースのセットアップ、実行、そしてスケーリングといった日常業務の面倒を見てくれます。

2012年にはじめてSQL Serverのサポートをローンチしました。それからSSLサポート、メジャーバージョンアップグレード、透過的なデータ暗号化、そしてMulti-AZといった多くの機能を追加してきました。これらの機能はRDS for SQL Serverの適用範囲を広げてより多くのユースケースへの扉を開きました。

多くの組織ではアカウントのクレデンシャルとそれに関連するアクセス権をActive Directoryに保管しています。ディレクトリによりこの情報に対する単一で一貫性のあるソースを提供し集中管理を可能にします。AWS Directory Serviceを使用してAWSクラウド上でMicrosoft Active DirectoryのEnterprise Editionを実行することができますので、次のステップにすすむときです！

Windows認証のサポート
AWS Directory Service for Microsoft Active Directory (Enterprise Edition)に保存されたクレデンシャルを使用してAmazon RDS for SQL Serverに対するアプリケーションの認証ができるようになりました。同じディレクトリにすべてのクレデンシャルを保持することでそれぞれのコピーをさがして更新する必要がなくなるため時間と手間の節約になります。

SQL Serverを実行するデータベースインスタンスを新規に作成するときにこの機能を有効にしてActive Directoryを選択することができます。既存のデータベースに対して有効にすることもできます。こちらが新規にデータベースインスタンスを作成するときにディレクトリを選択するやり方です（新規にディレクトリを作成することもできます）：

より詳細は、Using Microsoft SQL Server Windows Authentication with a SQL Server DB Instanceを読んでください。

いますぐ利用可能
この機能はUS East（北バージニア）、US West （オレゴン）、Europe（アイルランド）、Asia Pacific（シドニー）、Asia Pacific（東京）、そしてAsia Pacific（シンガポール）リージョンでいますぐ利用可能ですので今日からつかいはじめることができます。この機能に追加費用はありませんが、AWS Directory Service for Microsoft Active Directoryの通常料金がかかります。

— Jeff;（日本語訳はSA渡邉（@gentaw0）が担当しました。原文はAmazon RDS for SQL Server – Support for Windows Authentication）

データの暗号化をシンプルにし、アプリケーションの可用性を向上する新しいAWS Encryption SDKの利用法

by AWS Japan Staff | on 24 MAR 2016 | in AWS SDK, セキュリティ | Permalink

本日、AWSの暗号化チームは AWS Encryption SDKを発表します。この新しいSDKによって、開発者は、アプリケーションのセキュリティに影響を及ぼしうるエラーを最小化しながら容易に暗号化を実施できます。新しいSDKはAWSのお客様でなくてもご利用いただけますが、AWSのお客様にとってすぐに利用可能なサンプルが含まれています。

暗号化を行う際、開発者は次の2つの問題によく直面します:

どのように正しく暗号鍵を生成し、利用するか
利用後、鍵をどのように保護するか

新しいAWS Encryption SDKによって提供されるライブラリは、ユーザーの開発環境で利用可能な暗号化プロバイダを利用し、低レベルの詳細な部分を透過的に実装することで1つ目の問題に対応します。また、どのように鍵を保護したいかを選択できる直感的なインターフェースを提供することで2つ目の問題への対応を手助けします。開発者は、暗号化の複雑性ではなく構築しようとしているアプリケーションコアにフォーカスすることが出来ます。この記事では、AWS Encryption SDKを利用してどのようにデータの暗号化プロセスを簡素化できるか、単一のリージョンあるいは鍵管理ソリューションに縛られない、アプリケーションの可用性を改善するのに役立つ方法でどのように鍵を保護できるかについてお伝えします。

エンベロープ暗号化と新しいSDK

AWS Encryption SDKを利用する際に理解しておくべき重要なコンセプトは、エンベロープ暗号化(ハイブリッド暗号化としても知られています)です。アルゴリズムが違えば強度も異なり、単一のアルゴリズムで全てのユースケースにフィットするものは有りません。例えば、(RSAやAWS Key Mangement Service [KMS]などの)優れた鍵管理の特性を持つソリューションは、大容量のデータに対してはあまり有効ではありません。エンベロープ暗号化は、(AES-GCMのように)大容量データに適した単一用途のデータキーを使ってバルクデータを暗号化することでこの問題を解決します。エンベロープ暗号化ではその後、鍵管理に適したアルゴリズムや他のソリューションを使ってデータキーを暗号化します。

エンベロープ暗号化のもう一つの優位性は、複数の受信者で復号化できるようひとつのメッセージを暗号化できることです。全員で鍵を共有(これはたいていセキュアではありません)したり、全体のメッセージを複数回暗号化したり(これは現実的ではありません)するのではなく、データキーだけがそれぞれの受信者の鍵を使って暗号化されます。これによって重複した処理を顕著に削減でき、複数の鍵を利用した暗号化がより実用的になります。

エンベロープ暗号化の問題点は実装の複雑さです。全てのクライアントはデータフォーマットの生成および構文解析ができ、複数の鍵とアルゴリズムをハンドルでき、理想的には妥当な範囲で前方および後方互換性を保てる事が必須になります。

AWS Encryption SDKはどう役立つのか？

AWS Encryption SDKは、セキュアなアルゴリズムの組み合わせ(将来的に拡張可能)をサポートし、マスターキーのタイプやアルゴリズムの制限が無い、慎重にデザインされレビューされたデータフォーマットを採用しています。AWS Encryption SDK自身は、KMS、および AWS CloudHSMやその他の PKCS #11デバイスを含むJava Cryptography Architecture (JCA/JCE)を直接サポートするpoduction-readyなリファレンスJava実装です。他言語でのSDKの実装については現在開発中です。

AWS Encryption SDKの一つの利点は、低レベルの暗号処理はSDKで取り扱われるため、データの移動にフォーカスすることができることです。次に、パワフルでセキュアなマルチリージョンソリューションを構築する簡単なコードを示します。

Example 1:高可用性のためにアプリケーションの機密データを複数リージョンのKMSマスターキーで暗号化する

高可用性アプリケーションのベストプラクティスの一つは、複数のアベイラビリティゾーンだけではなく複数のリージョンでデプロイすることです。KMSはリージョンをまたがってカスタマーマスターキー(CMK)を共有できないため、データがKMSで暗号化されている場合にはこのようなデプロイメントは困難です。エンベロープ暗号化では、異なるリージョンの複数のKMS CMKを使ってデータキーを暗号化することでこの制限に対するワークアラウンドを取ることができます。各リージョンで稼働するアプリケーションは暗号文の復号化を行うために、高速で信頼性の高いアクセスのためにローカルのKMSエンドポイントを利用することができます。

このドキュメントの全ての例において、 IAM roles for EC2を設定したAmazon EC2インスタンスが稼働していることを想定しています。IAM Roleによってクレデンシャルの管理を避けることができ、最も近いエンドポイントへのリクエストができるビルトインロジックのアドバンテージがあります。また例では、AWS SDK for Java (AWS Encryption SDKとは異なります)の利用と、Bouncy Castleが利用可能であることを想定しています。

暗号化ロジックはとてもシンプルなハイレベルデザインを持っています。コマンドラインからパラメーターを読み込んだ後、マスターキーを取得してファイルを暗号化するのに利用するというものです(次のコードサンプルに示します)。不足しているメソッドに関してはこの記事の後続部分に記載します。

public static void main(final String[] args) throws Exception {
    // Get parameters from the command line
    final String inputFile = args[0];
    final String outputFile = args[1];

    // Get all the master keys we'll use
    final MasterKeyProvider<?> provider = getMasterKeyProvider();

    // Actually encrypt the data
    encryptFile(provider, inputFile, outputFile);
}

マスターキーを複数作成して一つのマスターキープロバイダーにまとめる

次のコードサンプルでは、3つの米国リージョン:us-east-1,us-west-1,us-west2のCMKを利用してデータをどう暗号化するかを示します。この例では、各リージョンのCMKをセットアップ済みでそれぞれのCMKに対してalias/exampleKeyという名前のエイリアスを作成しています。CMK作成の詳細については、AWS KMSドキュメントのCreating Keysをご参照下さい。

次にこの例では、全てのマスターキーを一つのマスターキープロバイダーにまとめるために MultipleProviderFactory を利用しています。最初のマスターキーは新しいデータキーを生成するのに利用され、他のマスターキーは新しいデータキーを暗号化するために利用されることに注目して下さい。

private static MasterKeyProvider<?> getMasterKeyProvider() {
    // Get credentials from Roles for EC2
    final AWSCredentialsProvider creds = 
        new InstanceProfileCredentialsProvider();

    // Get KmsMasterKeys for the regions we care about
    final String aliasName = "alias/exampleKey";
    final KmsMasterKey useast1 = KmsMasterKey.getInstance(creds,
                "arn:aws:kms:us-east-1:" + ACCOUNT_ID + ":" + aliasName);
    final KmsMasterKey uswest1 = KmsMasterKey.getInstance(creds,
                "arn:aws:kms:us-west-1:" + ACCOUNT_ID + ":" + aliasName);
    final KmsMasterKey uswest2 = KmsMasterKey.getInstance(creds,
                "arn:aws:kms:us-west-2:" + ACCOUNT_ID + ":" + aliasName);

    return MultipleProviderFactory.buildMultiProvider(
        useast1, uswest1, uswest2);
}

開発を簡素化し、全ての暗号化データを企業の標準に適合させるためのMasterKeyProviderを構成するロジックは、一度セキュリティチームによって作成すれば、企業をまたがって再利用できます。

データを暗号化する

暗号化対象のデータは、どこからでも取得できますし、どのような形でも配布できます。次のコードサンプルでは、ディスクからファイルを読み取り、暗号化コピーを書き出しています。AWS Encryption SDKはこれを簡単に実現するため、Javaストリームとダイレクトに統合されています。

private static void encryptFile(final MasterKeyProvider<?> provider,
        final String inputFile, final String outputFile) throws IOException {
    // Get an instance of the encryption logic
    final AwsCrypto crypto = new AwsCrypto();

    // Open the files for reading and writing
    try (
            final FileInputStream in = new FileInputStream(inputFile);
            final FileOutputStream out = new FileOutputStream(outputFile);
            // Wrap the output stream in encryption logic
            // It is important that this is closed because it adds footers
            final CryptoOutputStream<?> encryptingStream =
                    crypto.createEncryptingStream(provider, out)) {
        // Copy the data over
        IOUtils.copy(in, encryptingStream);
    }
}

例えば、このファイルにはアプリケーションの機密データ(パスワード、証明書等)を含めることができ、それをEC2インスタンスのローンチの時に EC2 ユーザーデータとして送信することができます。

データを復号化する

次のコードサンプルは、EC2ユーザーデータのコンテンツを復号化し、指定したファイルに書き出します。AWS SDK for Javaは、デフォルトでローカルリージョンのKMSを利用します。ですので復号化はクロスリージョンコール無しに素早く処理されます。

public static void main(String[] args) throws Exception {
    // Get parameters from the command line
    final String outputFile = args[0];

    // Create a master key provider that points to the local
    // KMS stack and uses Roles for EC2 to get credentials.
    final KmsMasterKeyProvider provider = new KmsMasterKeyProvider(
        new InstanceProfileCredentialsProvider());

    // Get an instance of the encryption logic
    final AwsCrypto crypto = new AwsCrypto();

    // Open a stream to read the user data
    // and a stream to write out the decrypted file
    final URL userDataUrl = new URL("http://169.254.169.254/latest/user-data");
    try (
            final InputStream in = userDataUrl.openStream();
            final FileOutputStream out = new FileOutputStream(outputFile);
            // Wrap the input stream in decryption logic
            final CryptoInputStream<?> decryptingStream =
                    crypto.createDecryptingStream(provider, in)) {
        // Copy the data over
        IOUtils.copy(decryptingStream, out);
    }
}

おめでとうございます！これで複数のリージョンのマスターキーで暗号化されたデータを、常にローカルのKMSスタックを使って復号化するコードを得たことになります。これで、1つの暗号文を管理するだけで、高い可用性と低レイテンシーな復号化を実現することができます。

Example 2: エスクローとポータビリティのためにアプリケーションの機密データを異なるプロバイダーのマスターキーで暗号化する

複数のマスターキーでデータを暗号化したいもう一つの理由として、鍵管理を単一のプロバイダに頼る事を避けるためというものがあります。単一の鍵管理ソリューションと抱合せにならないことにより、アプリケーションの可用性を改善することができます。このアプローチは、コンプライアンス要件やデータ損失からの防御、災害対策の要件によって複数のプロバイダを必要とする場合に役立つかもしれません。

エスクローのためのデータ暗号化や、プライマリのプロバイダと独立した追加の復号化マスターキーを利用するために、この記事で先ほど紹介したものと同様のテクニックが使えます。この例では、RSAの公開鍵と、KMSとは独立したオフラインハードウェアセキュリティモジュール(HSM)のような鍵管理インフラストラクチャに保管されている秘密鍵を、追加のマスターキーとしてどのように利用するかを示します。(RSAキーペアの生成と管理はこの記事の対象外とします)

データを公開マスターキーで暗号化する

データを暗号化するためにいくつかのKmsMasterKeysを作成した先ほどのコードサンプルと同様に、次のコードサンプルはRSA公開鍵を利用するもう一つのMマスターキーを作成します。この例では、Java Cryptography Extensions (JCE)のjava.security.PublicKeyオブジェクトを利用するためにJceMasterKeyを利用します。この例では、新しいマスターキーを(他の全てのマスターキーと一緒に)MultipleProviderFactoryに渡します。この例では、rsa_public_key.derというファイルから公開鍵を読み込みます。

private static MasterKeyProvider<?> getMasterKeyProvider()
      throws IOException, GeneralSecurityException {
    // Get credentials from Roles for EC2
    final AWSCredentialsProvider creds =
        new InstanceProfileCredentialsProvider();

    // Get KmsMasterKeys for the regions we care about
    final String aliasName = "alias/exampleKey";
    final KmsMasterKey useast1 = KmsMasterKey.getInstance(creds,
            "arn:aws:kms:us-east-1:" + ACCOUNT_ID + ":" + aliasName);
    final KmsMasterKey uswest1 = KmsMasterKey.getInstance(creds,
            "arn:aws:kms:us-west-1:" + ACCOUNT_ID + ":" + aliasName);
    final KmsMasterKey uswest2 = KmsMasterKey.getInstance(creds,
            "arn:aws:kms:us-west-2:" + ACCOUNT_ID + ":" + aliasName);

    // Load the RSA public key from a file and make a MasterKey from it.
    final byte[] rsaBytes = Files.readAllBytes(
        new File("rsa_public_key.der").toPath());
    final KeyFactory rsaFactory = KeyFactory.getInstance("RSA");
    final PublicKey rsaKey = rsaFactory.generatePublic(
        new X509EncodedKeySpec(rsaBytes));
    final JceMasterKey rsaMasterKey =
        JceMasterKey.getInstance(rsaKey, null,
            "escrow-provider", "escrow",
            "RSA/ECB/OAEPWithSHA-256AndMGF1Padding");

    return MultipleProviderFactory.buildMultiProvider(
        useast1, uswest1, uswest2, rsaMasterKey);
}

秘密鍵を利用した復号化

多くのHSMは、標準的なJava KeyStoreインターフェースをサポートしています。あるいは、少なくともJava KeyStore 実装を使うことができるPKCS ＃11ドライバーを提供しています。次の復号化コードサンプルでは、KeyStoreから取り出したRSA秘密鍵を利用しています。

public static void main(String[] args) throws Exception {
    // Get parameters from the command line
    final String inputFile = args[0];
    final String outputFile = args[1];

    // Get the KeyStore
    // In a production system, this would likely be backed by an HSM.
    // For this example, it will simply be a file on disk
    final char[] keystorePassword = "example".toCharArray();
    final KeyStore keyStore = KeyStore.getInstance("JKS");
    try (final FileInputStream fis = new FileInputStream("cryptosdk.jks")) {
        keyStore.load(fis, keystorePassword);
    }

    // Create a master key provider from the keystore.
    // Be aware that because KMS isn’t being used, it cannot directly
    // protect the integrity or authenticity of this data.
    final KeyStoreProvider provider = new KeyStoreProvider(keyStore,
            new PasswordProtection(keystorePassword),
            "escrow-provider", "RSA/ECB/OAEPWithSHA-256AndMGF1Padding");

    // Get an instance of the encryption logic
    final AwsCrypto crypto = new AwsCrypto();

    // Open a stream to read the encrypted file
    // and a stream to write out the decrypted file
    try (
            final FileInputStream in = new FileInputStream(inputFile);
            final FileOutputStream out = new FileOutputStream(outputFile);
            // Wrap the output stream in encryption logic
            final CryptoInputStream<?> decryptingStream =
                    crypto.createDecryptingStream(provider, in)) {
        // Copy the data over
        IOUtils.copy(decryptingStream, out);
    }
}

結論

エンベロープ暗号化はパワフルですが従来は実装が難しいものでした。新しいAWS Encryption SDKはユーザーがデータキーを管理する助けとなり、複数のマスターキーでデータを暗号化するプロセスを簡素化します。結果、この新しいSDKを利用することでビジネスを前進させるコードにフォーカスすることができます。またこのSDKは、ユーザーの標準に適合、強制させる為に構成された暗号化ライブラリを利用しなければならない場合にも容易に拡張ができるフレームワークを提供します。

AWS Encryption SDKをリリースする事をとても嬉しく思っており、このSDKを利用して皆様が何をするかを伺うのを待ちきれません。新しいSDKやこの記事についてコメントのある方は、下記のコメントセクションにお願いします。実装や使い方に対する質問のある方は、KMS forumまでお願い致します。

– Greg(翻訳はSA布目が担当しました。原文はこちら)

CloudWatch Metrics for Spot Fleets

by AWS Japan Staff | on 23 MAR 2016 | in Amazon CloudWatch, EC2 Spot Instances | Permalink

スポットフリートは、ほんの数クリックでご利用頂けます。利用を始めるとフリートのサイズに関係なく（1台のインスタンスから何千台のインスタンスまで）費用対効果の高いキャパシティを複数プールからリソース提供します。この強力なEC2機能の詳細については、こちらのブログを参照下さい。【AWS発表】Amazon EC2 スポットフリート API – 一度のリクエストで数千台のスポットインスタンスを制御、【AWS発表】Spotフリート – コンソール、フリートスケーリング、CoudFormationに対応。

私は各スポットフリートを一つの集合体として考えます。フリートが起動すると、それぞれが独立したグループのEC2インスタンスとして起動します。スポット価格の変化や、フリートキャパシティの変更に伴いインスタンスの状態は変化しますが（可能な限り費用対効果を高めるよう変化）、フリート自体はその属性を保持します。

新しいスポットフリートメトリックス

スポットフリートの管理、監視、拡張性をより簡単にするために、CloudWatchに新しいスポットフリート用メトリックが追加されました。メトリックスは、複数のディメンションからアクセスできます：スポットフリート毎、スポットフリートが構成されているアベイラビリティゾーン毎、フリート内のEC2インスタンスタイプ、アベイラビリティゾーン、インスタンスタイプ等。

下記メトリックスは各スポットフリート毎に取得されます。（これらメトリックスを取得するためには、EC2詳細モニタリングを有効にする必要があります）

AvailableInstancePoolsCount
BidsSubmittedForCapacity
CPUUtilization
DiskReadBytes
DiskReadOps
DiskWriteBytes
DiskWriteOps
EligibleInstancePoolCount
FulfilledCapacity
MaxPercentCapacityAllocation
NetworkIn
NetworkOut
PendingCapacity
StatusCheckFailed
StatusCheckFailed_Instance
StatusCheckFailed_System
TargetCapacity
TerminatingCapacity

メトリックのいくつかは、スポットフリートの入札プロセスのヒントとなるかもしれません。例えば、

AvailableInstancePoolsCount – スポットフリートのリクエストに含まれるインスタンス・プールの数を示します。
BidsSubmittedForCapacity – スポットフリートキャパシティの入札数を示します。
EligibleInstancePoolsCount – スポットインスタンスリクエストの対象となるインスタンスプールの数を示します。いずれか（1）スポット価格がオンデマンド価格より高い場合、または（2）入札価格がスポット価格よりも低い場合にはプールが不適用となります。
FulfilledCapacity – フリートキャパシティを満たす容量の合計を示します。
PercentCapacityAllocation – 特定ディメンションに割り当てられた容量の割合を示します。特定のインスタンスタイプに割り当てられた容量のパーセントを決定するために、インスタンスタイプと共に使用することができます。
PendingCapacity – ターゲットキャパシティと利用済みキャパシティの差異を示します。
TargetCapacity – スポットフリート内の現在要求されたターゲットキャパシティを示します。
TerminatingCapacity – スポットインスタンスの終了通知を受けたインスタンスのインスタンスキャパシティを示します。

これらのメトリックスは、スポットフリートの全体的なステータスとパフォーマンスを決定する手助けになります。メトリック名からも分かりますが、スポットフリート毎に消費されるディスク、CPU、およびネットワークリソースを確認することができます。また、スポットキャパシティ確保のために入札の前にどのような傾向があるかを確認することができます。それに加え、アベイラビリティゾーン、インスタンスタイプをまたいだ下記メトリックスも取得できます。

CPUUtilization
DiskReadBytes
DiskReadOps
DiskWriteBytes
FulfilledCapacity
NetworkIn
NetworkOut
StatusCheckFailed
StatusCheckFailed_Instance
StatusCheckFailed_System

これらのメトリックスを利用することでアベイラビリティゾーン、インスタンスタイプをまたいだの負荷の許容可能な分布確認をすることができます。

フリート全体の使用率を把握するためにMax、Min、またはAvgを使用しメトリックを集計することができます。一方で、2種類以上のインスタンスからなるフリートでは、Avgを使用すること自体意味がないことにもご注意ください！

利用可能

この機能はすでにご利用頂けます。

— Jeff (翻訳は酒徳が担当しました。本文はこちら：https://aws.amazon.com/jp/blogs/aws/new-cloudwatch-metrics-for-spot-fleets/)

Redshiftアップデート：COPYやVACUUMの機能向上、クラスターリサイズの速度向上等

by AWS Japan Staff | on 21 MAR 2016 | in Amazon Redshift | Permalink

Redshiftの新しいバージョン1.0.1040リリースについて、その新機能や修正一覧の説明とメンテナンスの予告が公開されています。

このリリースには以下の新機能が含まれています。

ユーザが定義したしきい値よりも大きい比率でソート済の表は、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 が Elasticsearch Service と CloudWatch に連携できるようになりました

by AWS Japan Staff | on 16 MAR 2016 | in AWS IoT | Permalink

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/

AWS Database Migration Service (DMS)が一般公開に！利用可能リージョンも拡大

by AWS Japan Staff | on 16 MAR 2016 | in AWS Database Migration Service | Permalink

みなさんは、現在リレーショナルデータをオンプレミスの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 going forward（差分レプリケーションのみ実行）”の３種類から選択が可能です。

Task Settingsをクリックすることで、追加のオプションを選択可能です（LOBというのはラージオブジェクトのことです):

マイグレーションタスクが準備完了になりました。タスクを選択してStart/Resumeボタンを押すことですぐに実行することが可能です:

実行中の状況を確認することが可能です。また表へのアクセスの統計情報(Table statistics)によって、何が起こっているのかを把握することが可能です（この図はテスト用の表を使った結果なので、あまりエキサイティングな図ではないですが）:

ここまで来たら、あとはデータの正当性をチェックし、アプリケーションを新しいエンドポイントに向けるだけです。上記は一括ロードの例ですが、継続的なレプリケーション(ongoing replication)を選択することも可能です。

AWS Database Migration Serviceは多様なオプションを提供しており、上記はあくまで少し機能を紹介したに過ぎません。例えば、特定の表だけをマイグレーションしたり、複数の異なるレプリケーションタスクを作成し、それぞれ個別に実行することも可能です。DMSのドキュメントを読まれることを強く推奨します。マイグレーションを始めて行う人向けの良いガイドになっています。

多くのデータベースを移行する必要があり、作業を自動化したい場合は、AWS Command Line Interface (CLI) もしくはDatabase Migration Service APIを利用することができます。

費用と稼動リージョン

AWS Database Migration Serviceは US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore), Asia Pacific (Sydney) の各リージョンに存在します。そして本日より利用可能です！（私達は他のリージョンへの拡張を今後数ヶ月で検討しています）

— Jeff;

原文：https://aws.amazon.com/jp/blogs/aws/aws-database-migration-service/

翻訳：下佐粉　昭（@simosako）

Amazon Auroraのリードレプリカで、フェイルオーバーの順番を指定可能になりました

by AWS Japan Staff | on 16 MAR 2016 | in Amazon RDS | Permalink

本日、Amazon Auroraクラスタ中のレプリカノードを昇格させる順番をご指定頂けるようになりました。この機能により、フェイルオーバ発生時のレプリカノードの昇格を扱いやすくなりました。マスターインスタンスに障害などが発生した場合、Amazon RDSは優先順位が高いレプリカノードを昇格させます。低い優先順位を指定することで昇格させたくないレプリカインスタンスをご指定頂けます。例えば、バッチや集計用途などでご利用頂いているレプリカノードに対して低い優先順位を指定することで、昇格を防ぎバッチや集計作業の影響をアプリケーションに与えることを防ぐことも可能です。

フェイルオーバの優先順位は

指定した優先度
優先度が同じレプリカが複数ある場合は、フェイルオーバ発生時のマスターインスタンスよりインスタンスサイズの大きいインスタンス
優先順位もインスタンスサイズも同じ場合は、同じ優先順位のレプリカノードから任意のレプリカノードが選択されます

さらに詳細なフェイルオーバのロジックや優先順位についてはAmazon Auroraユーザガイドをご覧ください。Amazon Auroraについてはプロダクト紹介ページをご覧ください。

— 星野 (原文はこちら)

10 Lessons from 10 Years of Amazon Web Services ～ AWS10年に学ぶ10のレッスン

by AWS Japan Staff | on 15 MAR 2016 | in General | Permalink

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は、それぞれのデータブロックはデフォルトでランダムキーで暗号化され、そのキーの集合はマスターキーで再度暗号化されています。マスターキーはお客様だけが知る唯一のキーで、ビジネスデータまたは個人情報にアクセスするための復号キーとなります。

暗号化は我々のビジネスにとって優先度の高い事項です。お客様にとってより簡単に使える暗号化の手段を継続して提供し、データやお客様をより強固に守ります。

9. ネットワークの重要性

AWSは多くの異なるワークロードに対応してきました。高トランザクション処理から動画変換、高度計算処理から大量のウェブアクセスまで規模を拡大しながら対応できます。これらのワークロードはネットワークにおいては独自の要件があります。

AWSはデータセンターの構成や運用に対して独自のスキルを有しており、お客様のワークロードがいかなるものであっても、それに対応した柔軟なネットワークインフラを持っています。我々は、お客様の達成したい目標に合わせて実現することに対して、ハードウェアまで独自に構築することもいといません。つまり、とても特殊な要件に対しても実現することを可能にし、AWSのネットワークを使用すればお客様が高いセキュリティの担保と差別化が可能になります。

どのようにAWS指定のネットワークハードウェアとソフトウェアでお客様のパフォーマンス改善しているかという成功事例でいうと、仮想マシンから仮想化されたネットワーク上での負荷を分散し解決する事でした。なぜならば、ネットワークアクセスは共有リソースであり、お客様が以前ネットワークアクセスで遅延を感じたこともあるからです。シングルルートの仮想I/Oに対応したNICの開発は独自のVMのハードウェア上にある仮想化NIC実装を可能にしました。これにより遅延に関しては2倍以上高速になり、ネットワーク上の実測では10倍もの改善になっています。

10. イノベーションに制限なし

AWSは、お客様に対して幅広で深いプラットホームを実現する為、様々な機能やサービスを提供しています。しかし、AWSはインハウスで構築するサービスはそれほど多くありません。パートナーエコシステムを活用し、様々な新たな方向にプラットホームを拡張しています。

例えば、StripeというパートナーはTwilioがAWS上でビジネスができるよう支払いサービスを提供しています。お客様の多くは提供するサービスの深さに対応する為のAWS上のサービスを構築しています。Philipsは健康に関するデジタルプラットホームを健康維持のためのデータ管理に使っています。OhpenはAWS上に少額バンキング向けのプラットホームを構築しています。Eagle Genomicsはゲノム解析のプラットホームを構築しています。他にもいろいろあります。肝心なことは、AWSプラットホーム上には、制限をかけるものは何もないので、やりたい事を実現すればいいのです。「制限がない」というのは、イノベーションに向けた開放で、思いがけない多くの発明の扉を開けるでしょう。

我々が今後学んでいくことが何か楽しみにしています。AWSのお客様が10年後に達成していることもです。覚えておいてください、今日がいつでも「初日」（Day 1）であることを・・・

——————–

（翻訳は石橋が担当しました。）

Ten Years in the AWS Cloud – How Time Flies! ～ AWSクラウドの10年

by AWS Japan Staff | on 14 MAR 2016 | in General | Permalink

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 　VPCのデビューでした。これにより勇み足なエンタープライズITにおいてもAWSを使い始めました。ネットワークの論理的な分離が必要で、AWSが実現したことを喜んでいました。

インターネット時代のデータストレージ (2012) – Amazon DynamoDB ローンチ当時はNoSQLはまだまだ黎明期でした。今では、マーケットは見えつつあり、お客様が大規模データをDynamoDBで扱うことや要望を沢山聞くようになりました。

数分で構築できるデータウェアハウス (2012) – Amazon Redshift 多くの企業がデータウェアハウスの稼働に1四半期から年単位で時間を要しています。Amazon Redshiftは、すぐに始められる方法を提供しています。

クラウドでデスクトップ仮想化 (2013) – Amazon WorkSpaces あまり関係ないかすごくいいのどちらかで、見過ごされることが多いですが、デスクトップの仮想化は私にとってもお客様にとっても生産性向上の為に重要になってきています。

リアルタイム分析？どのくらいのデータ量？ (2013) – Amazon Kinesis データ取得、解析、結果の取得を大量のストリームデータから、簡単に取り出せます。

新たなプログラミングモデル～サーバレス (2014) – AWS Lambda このサービスも破壊的で革新的です。多くのエンタープライズで、Lambdaの使い方をマスターした、洗練された利用が開始されていることがとても印象深いです。スタートアップで利用する、アプリをサーバレスに置き換えるといったLambdaの使われ方を期待しています。

デバイスの未来 (2015) – AWS IoT 大量生産されている計算能力と広域のIP接続が可能にする、モノのインターネット。各種のデバイスがつながります。

Moving Forward ～その先へ
10年前、クラウドコンピューティングのリスクが適用時の主な懸念点でした。それは、新しく、実証のない、答えのないものに対する懸念でした。その時代はいつしか過ぎ去りました。最近では、クラウドへ移行しないことのリスクが会話としてあるのを聞いたことがあります。どのような規模や形態の組織も、素早く、最新のインフラを利用し、同じものを使うことでプロを喜ばせることができるのではないでしょうか。今日の社員は、最新ではやりの技術を使って生産性を上げたいはずです。

次のクラウドの10年は、過去の10年と同じくらいエキサイティングであると確信しています。学び、開発し、あなたの成功を私たちに共有してください！