Amazon Web Services ブログ

AWS Marketplace では、すばらしいことがたくさん起きています。こちらで、マーケットプレイスのオープンソースソフトウェアについての詳細を、Matthew Freeman および Luis Daniel Soto が説明します。 – Ana 業界の調査によると、企業が使用するオープンソースソフトウェア (OSS) は増加しています。ますます多くの企業の開発者は、現在進行中の開発作業の一環として、利用可能な OSS ライブラリを使用するように求めています。これらの開発者は、自分のプロジェクト (夜間および週末など) で OSS を使用していることがあり、その場合自然に別の場所でもそのツールおよびテクニックを使用したいと考えます。そのため、すべての部門の開発組織は、販売するソフトウェアだけでなく、自社の IT インフラストラクチャ内のアプリケーションにオープンソースソフトウェアを使用するケースを検討しています。この概要では、AWS を通したオープンソースソフトウェアの入手が開発および財務の観点から理にかなっている理由について説明します。 オープンソース開発プロセス オープンソースソフトウェアは、一般的に参加者の独立したコミュニティで開発されるため、ソフトウェアのバージョンの取得および管理は、通常オンラインコードリポジトリを通して行われます。異なるソースからのコードを使用すると、コードライブラリおよび開発ツールを取得して共に機能させることが困難となる場合があります。しかし、AWS Marketplace は、このプロセスをスキップして、必要な OSS で EC2 インスタンスを直接起動できます。AWS Marketplace には、OSS ソリューションの基盤として使用できる Linux のディストリビューションもあります。 構成済みのスタックが与えるメリット 市販のソフトウェアでこの 1-Click 起動機能は当然のことと考えるかもしれませんが、OSS にとって構成済みの AMI を実装していることには大きなメリットがあります。AWS Marketplace は、最も一般的なオープンソースソフトウェアの組み合わせ、または「スタック」を作成するソフトウェア会社に、これらのスタックを AWS クラウドに起動できる場所を提供します。TurnKey および Bitnami のような企業は、OSS のエキスパートを使って、ソフトウェアが共にうまく機能するようにこれらのコードスタックを設定および最適化します。これらの企業は、OSS のリリースを最新の状態に保ち、新しいバージョンが利用可能になるとすぐにスタックを更新します。これらの企業の中には、クラウドベースのサーバーの起動および管理をさらに容易にするために、クラウドホスティングインフラストラクチャを有料サービスとして提供しているものもあります。たとえば、オープンソースソフトウェアの最も一般的な組み合わせの 1 つは、LAMP スタックで、Linux […]

2016 年は AWS Lambda、Amazon API Gateway、そして、サーバーレスコンピューティングテクノロジーにとって、控えめに言ってもすばらしい年となりました。もしかすると、AWS Lambda および Amazon API Gateway でのサーバーレスコンピューティングについて耳にしたことがない方がいらっしゃるかもしれませんので、これらのすばらしいサービスについてご紹介したいと思います。AWS Lambda を使用すると、サーバーをプロビジョニングまたは管理しなくてもコードを実行できます。このイベント駆動型のサーバーレスコンピューティングサービスにより、開発者は、ほぼすべての種類のアプリケーションまたはバックエンドで機能を簡単にクラウドへ移行できます。Amazon API Gateway は非常にスケーラブルで、信頼性が高く、堅牢な API を大規模にすばやく構築するのに役立ち、作成した API の維持およびモニタリングの機能も提供します。2016 年のサーバーレスの勢いの締めくくりとして、AWS チームは re:Invent でサーバーレスソリューションの構築をさらに簡単にする強力なサービス機能を発表しました。その機能には次のものがあります。 AWS Greengrass: Lambda および AWS IoT を使用して、接続された IoT デバイスのローカルでのコンピューティング、メッセージング、データのキャッシングを実行します。https://aws.amazon.com/blogs/aws/aws-greengrass-ubiquitous-real-world-computing/ Lambda@Edge Preview: グローバル AWS エッジロケーションでコードを実行でき、Amazon CloudFront のリクエストに応じてトリガーされることで、エンドユーザーのネットワークレイテンシーを削減できる Lambda の新しい機能です。https://aws.amazon.com/blogs/aws/coming-soon-lambda-at-the-edge/ AWS Batch Preview: 今後予定されているバッチジョブとしての Lambda 統合を含む AWS コンピューティングサービスにおけるワークロードの計画、スケジューリング、実行のコンピューティング用バッチです。https://aws.amazon.com/blogs/aws/aws-batch-run-batch-computing-jobs-on-aws/ AWS X-Ray: マイクロサービスアーキテクチャを使用してビルドされたもの、Java、Node.js、.NET で記述されたもの、EC2、ECS、AWS […]

re:InventでMySQLデータベースと互換性があり、コマーシャルデータベースの性能と可用性、オープンソースデータベースのコストパーフォーマンスの両面をそなえた、Amazon Auroraの新機能を発表しました。 今日、advanced auditing機能が全てのお客様にご利用頂けるようになったことを発表致します。 advanced auditingとは Auditingとは特定のイベントを収集して手動もしくは他のアプリケーションで分析出来るように提供する機能を指します。これらのログはコンプライアンス規定やガバナンスのベースになる情報として利用可能です。advanced auditingの例には、ログ分析、ユーザーアクションの監査(過去のイベントおよび、ニアリアルタイムの脅威検出など)、セキュリティ関連のイベントに設定されたアラームのが含まれます。 Auroraのadvanced auditing機能は、データベースのパフォーマンスに与える影響を最小限に抑えながら、これらの機能を提供するように設計されています。 advanced auditingを利用するには まずはじめに、advanced auditingを有効にし、audit logを参照します。 advanced auditingの有効化 DBクラスタパラメータグループにあるパラメータを設定することでadvanced auditingの有効化や設定を行うことができます。これらのパラメータの変更がDBクラスタの再起動は必要ありません。また、動作は Aurora DB instance parametersと同様です。 機能を有効/無効化するために server_audit_loggingパラメータを利用します。server_audit_eventsパラメータでどのイベントをログに記録するか設定します。 server_audit_excl_usersとserver_audit_incl_usersパラメータでどのユーザを監査対象にするか設定可能です: server_audit_excl_usersとserver_audit_incl_usersが未指定の場合(デフォルト値)は全てのユーザが記録されます server_audit_incl_usersにユーザを設定し、server_audit_excl_usersを指定しない場合、server_audit_incl_usersに指定したユーザのみ記録されます server_audit_excl_usersにユーザを設定し、server_audit_incl_usersを指定しない場合、server_audit_excl_usersに指定したユーザ以外が記録の対象になります server_audit_excl_usersとserver_audit_incl_usersに同一のユーザを設定した場合は、server_audit_incl_usersの優先度が高いため記録の対象になります advanced auditingのパラメータの詳細を以下でご説明します server_audit_logging　監査ログの有効/無効化を指定します。標準ではOFFになっているので、ONに指定することで有効になります Scope: Global Dynamic: Yes Data type: Boolean Default value: OFF (disabled) server_audit_events　イベントのリストをカンマで区切って指定します。リスト中のエレメント間にスペースは入れなように気をつけて下さい Scope: Global Dynamic: Yes Data type: String Default value: Empty […]

本日、Amazon ECSはクラスタ上にどのようにしてタスクを配置するかを汎用的に制御することのできる機能を発表しました。以前は、特定のリソースの要求(例えば、特定のインスタンスタイプ)を満たすコンテナインスタンス上にタスクを配置する必要がある時は、カスタムスケジューラを作成してリソースをフィルタし、発見し、グループ化する必要がありました。 次の図は、新しいタスク配置処理の概要を示しています: これによって、コードを一切書かずともタスクがどのように配置されるかをカスタマイズすることができます。ECSは、インスタンスタイプやアベイラビリティゾーンの様な組み込み済の属性を付与していますし、加えてカスタムの属性もサポートしています。例えば、environment=productionといった属性でコンテナインスタンスをラベル付することができ、これらのリソースを見つけるためにList APIで操作することや、RunTaskとCreateService API操作でこれらのリソース上にタスクを配置することができます。 また、bin packやspreadといったplacement strategy (配置戦略)を使って、タスクがさらにどこに配置されるかを定義することもできます。ポリシーを連鎖させて洗練された配置を達成することもできます。例えば、g2.*のインスタンス上にのみタスクを配置し、アベイラビリティゾーンに渡って幅広く(spread)配置し、そして各ゾーンではメモリを基準にタスクをなるべく詰め込む(bin pack)というポリシーを作成できます。 はじめに、attribute (属性)を見てましょう。インスタンスタイプ等の組み込み済の属性を使って、コンテナインスタンスを見つけ、その上にタスクを配置することができます。以下の例では、クラスタ上の全てのt2インスタンスを見ることができます: aws ecs list-container-instances –filter “attribute:ecs.instance-type matches t2.*” { “containerInstanceArns”: [ “arn:aws:ecs:us-east-1:123456789000:container-instance/40f0e62c-38cc-4cd2-a28e-770fa9796ca1”, “arn:aws:ecs:us-east-1:123456789000:container-instance/eb6680ac-407e-42a6-abd3-1bbf57d7401f”, “arn:aws:ecs:us-east-1:123456789000:container-instance/ecc03e17-6cbd-4291-bf24-870fa9796bf2”, “arn:aws:ecs:us-east-1:123456789000:container-instance/fbc03e17-acbd-2291-df24-4324ab342a24”, “arn:aws:ecs:us-east-1:123456789000:container-instance/f9a69f54-9ce7-4f1d-bc62-b8a9cfe8e8e5” ] } 続いて、us-east-1aのアベイラビリティゾーンにあるt2インスタンスのみをリストしています: aws ecs list-container-instances –filter “attribute:ecs.instance-type matches t2.* and attribute:ecs.availability-zone == us-east-1a” { “containerInstanceArns”: [ “arn:aws:ecs:us-east-1:123456789000:container-instance/40f0e62c-38cc-4cd2-a28e-770fa9796ca1”, “arn:aws:ecs:us-east-1:123456789000:container-instance/eb6680ac-407e-42a6-abd3-1bbf57d7401f”, “arn:aws:ecs:us-east-1:123456789000:container-instance/ecc03e17-6cbd-4291-bf24-870fa9796bf2” ] } カスタム属性はECSのデータモデルを自身のカスタムメタデータ用にキーバリューのペアを使って拡張します。以下の例では、stack=prodという属性を特定のコンテナインスタンスに追加しています: aws ecs put-attributes –attributes […]

2016 年 10 月後半に、著名な DNS プロバイダーが、複数のサービス妨害攻撃で構成された大規模なサイバー攻撃の標的となりました。数千万の IP アドレスからの大量の DNS 参照で構成された攻撃により、多くのインターネットサイトやサービスが北米および欧州のユーザーに対して利用できなくなりました。プリンター、カメラ、家庭用ネットワークゲートウェイ、さらにはベビーモニターといったさまざまなインターネッツ接続デバイスで構成されたボットネットを使用して、この分散サービス妨害 (DDoS) 攻撃が実行されたと考えられます。これらのデバイスは Mirai マルウェアに感染し、1 秒あたり数百ギガバイトのトラフィックを生成しました。多くの企業ネットワークや教育ネットワークは、このような規模のボリューメトリック攻撃を吸収するだけのキャパシティーを持っていません。この攻撃や、それ以前のその他の攻撃を受けて、さまざまなタイプの DDoS 攻撃に対してより弾力性の高いシステムを構築できるようにするための推奨事項やベストプラクティスについてお客様から当社に問い合わせがありました。簡単な回答としては、スケール、耐障害性、および緩和を組み合わせ (詳細については「AWS Best Practices for DDoS Resiliency」ホワイトペーパーを参照)、 および を利用することです (詳細については、「AWS Shield – Protect Your Applications from DDoS Attacks」を参照)。 スケール – Route 53 は数多くの AWS エッジロケーションでホストされ、大量の DNS トラフィックを吸収することができるグローバルな対象領域を作成します。 と を含むその他のエッジベースのサービスにもグローバルな対象領域があり、大量のトラフィックを処理することができます。 耐障害性 – 各エッジロケーションには、インターネットへの数多くの接続があります。これにより、多様なパスが可能になり、障害の分離と阻止に役立ちます。また、Route 53 はシャッフルシャーディングとエニーキャストストライピングを使って可用性を高めます。シャッフルシャーディングでは、委託セットの各ネームサーバーがエッジロケーションの一意のセットに対応します。この配置によって耐障害性が向上し、AWS のお客様間の重複が最小化されます。委託セットの 1 つのネームサーバーが利用できない場合、クライアントシステムまたはアプリケーションは別のエッジロケーションのネームサーバーを再試行し、レスポンスを受け取ります。エニーキャストストライピングは、最適な場所に DNS リクエストをダイレクトするために使用されます。これは、負荷を分散して […]

は、Chef を使用したアプリケーションの設定と実行に役立ちます。ドメイン固有言語 (DSL) を使って、アプリケーションのアーキテクチャと各コンポーネントの設定を定義するクックブックを記述します。Chef サーバーは、設定プロセスで不可欠な要素です。このサーバーはすべてのクックブックを保存し、各インスタンス (Chef の用語ではノード) の状態情報を追跡します。Chef サーバーは新しく起動されたインスタンスが設定されるときは重要なパスにあるため、信頼性が高い必要があります。多くの OpsWorks および Chef ユーザーは、この重要なアーキテクチャコンポーネントを自分でインストールして維持しています。本稼働スケールの環境では、これによりバックアップ、復元、バージョンのアップグレードなどをユーザーが処理する必要があります。 新しい AWS OpsWorks for Chef Automate 今月初めに、AWS OpsWorks for Chef Automate が ステージから開始されました。Chef Automate サーバーは、わずか 3 回のクリックで起動し、数分以内に使用を開始することができます。Chef Supermarket をはじめ、Test Kitchen や Knife などのコミュニティツールからのコミュニティクックブックを使用できます。Chef Automate を使用すると、アプリケーションのインフラストラクチャのライフサイクルを通じてインフラストラクチャを管理できます。たとえば、新しく起動した EC2 インスタンスは自動的に Chef サーバーに接続し、自動関連付けスクリプトを使用して、指定されたレシピを実行できます (詳細については、「AWS OpsWorks for Chef Automate でのノードの自動的な追加」を参照)。登録スクリプトを使用して、Auto Scaling グループを通じて動的に作成された EC2 インスタンスを登録し、オンプレミスサーバーを登録できます。 詳しく見る OpsWorks コンソールから […]

昨年、AWS のお客様とパートナーから、AWS のサービスの料金を取得するためのシステム的な方法を求める要望が寄せられました。このニーズに対して、昨年 12 月に 13 の AWS のサービスの料金を対象とした AWS の料金表 API を発表しました。この API は、ダウンロード用に JSON および CSV 形式で料金表データを提供し、お客様は AWS のサービスの料金を問い合わせることができます。料金表 API では、Amazon SNS 通知を通じて料金変更の更新情報を受け取ることもできます。 AWS 料金表の API の拡張 過去 3 か月に、当社は AWS の料金表 API サービスを拡張し、すべての AWS のサービスについて料金表データを提供するようにしました。クラウドベースのソリューションの構築またはクラウドへのオンプレミスワークロードの移行に関するコスト分析を行っているお客様は、AWS のサービスの包括的な料金表にこれまでよりも簡単にアクセスできます。これにより、お客様とパートナーは、クラウドソリューションの予算、予測、および計画をより詳細に管理できます。AWS の料金表 API の拡張に加えて、お客様はサインアップして割引料金、新しいサービスやインスタンスタイプの通知を受け取ることができます。通知の受信のサブスクライブの際は、更新情報を受け取るタイミングをカスタマイズでき、1 日 1 回、または料金の更新が発生するたびに設定できます。1 日 1 回の通知を選択した場合、SNS 通知にはその日に適用されたすべての料金変更が含まれます。料金表 API にサブスクライブした場合に受け取る E メール通知のサンプルを次に示します。 料金表 API […]

2016年末最後の数秒をカウントダウンする場合は、最後に1秒を追加するのを忘れないようにしてください！ 次回のうるう秒（通算27回目）が、UTC（世界標準時）の2016年12月31日 23:59:60として挿入されます（訳注：日本標準時では2017年1月1日 8:59:60になります）。これは地球上での時刻（協定世界時）と太陽時（天文時）とのずれを小さくするために行われ、この結果、UTCでは今年最後の1分は61秒あることになります。 参考）「うるう秒」挿入のお知らせ（総務省） 前回のうるう秒の際に出した情報（事前にご確認ください – AWSでのうるう秒対応）は引き続き有効で、今回も同様に処理されますが、少しの違いと進展があります: AWS調整時刻（AWS Adjusted Time） –うるう秒挿入前後の24時間の期間にわたって、うるう秒の1秒を少しずつ分散します（UTCで12月31日の11:59:59から、2017年1月1日12:00:00まで）。AWS調整時刻と協定世界時はこの期間が終了後に同期します。（訳注：この期間の１秒をごくわずかに遅くすることで、追加される１秒を長い時間のなかに分散する方法であり、これは前回うるう秒挿入時と同じ挙動です。詳しくは前回の情報をご確認ください。） Microsoft Windows – Amazonによって提供されたMicrosoft WindowsのAMIを利用しているインスタンスは、AWS調整時刻に従います。 Amazon RDS – 大多数のAmazon RDS インスタンスは （UTCで設定されている場合）“23:59:59” を2回記録します。しかし、Oracle 11.2.0.2、11.2.0.3、12.1.0.1 はAWS調整時刻に従います。Oracle 11.2.0.4と12.1.0.2について詳細な情報が必要な場合はAWSサポートにお問い合わせください。 サポートが必要ですか？ このうるう秒挿入についてご質問がある場合は、AWSサポートにコンタクトいただくか、EC2フォーラムにポストしてください。 — Jeff; 翻訳：下佐粉　昭（@simosako） 原文：https://aws.amazon.com/blogs/aws/look-before-you-leap-december-31-2016-leap-second-on-aws/

去年、EC2 Run Command をご紹介して、最初に EC2 インスタンスで、次いでハイブリッドおよびクラウド間の環境で大規模なリモートのインスタンス管理をするための使い方をご説明しました。その過程で、Linux インスタンスのサポートを追加したため、EC2 Run Command は幅広く応用できる非常に便利な管理ツールになりました。 ファミリーへようこそ Werner が EC2 Systems Manager を で発表したので、ついにお話しできるようになりました。これは、同じように便利な 8 つの機能と共に EC2 Run Command の強化版を含む新しい管理サービスです。EC2 Run Command と同様に、Windows と Linux を実行するインスタンスとサービスで構成されたハイブリッドおよびクラウド間の環境をサポートします。 を開き、管理するインスタンスを選択して、実施するタスクを定義します (API および CLI のアクセスも可能)。機能拡張と新機能の概要を次に示します。 Run Command – コマンドの実行速度を制御し、エラー率が高くなりすぎたときにコマンドの発行を停止できるようになりました。 State Manager – 定期的に適用される、ポリシーで定義されたシステム設定を維持します。 パラメーターストア – ライセンスキー、パスワード、ユーザーリスト、その他の値の一元管理型 (オプションで暗号化された) ストレージを提供します。 メンテナンス時間 – 更新のインストール、その他のシステムメンテナンスの時間枠を指定します。 ソフトウェアインベントリ – 各インスタンスから、詳細なソフトウェアおよび設定のインベントリ (ユーザー定義の追加を含む) […]

コストエクスプローラーは、レポートおよび分析ツールを使用して AWS の使用率を管理できるようにするツールです (詳細については、「The New Cost Explorer for AWS」を参照してください)。1 回クリックするだけでサインアップし、AWS コストの視覚化、傾向の分析、使用率のパターンの確認ができます。使用率は、事前定義された一連のビュー (サービス別、リンクされたアカウント別、日次など) で確認できます。関心のある特定の領域にドリルインしたり、カスタムフィルタを設定したりできます。エンタープライズ規模の AWS のお客様は、リザーブドインスタンスで実現されるコスト削減 (オンデマンドと比較した場合、最大 75%) を常に活用できます。こうしたお客様は、一般的に数千ものリザーブドインスタンス (RI) のサブスクリプションを持っていて、それらを十分に活用できていることを確認したいと考えています。 新しいリザーブドインスタンス使用率レポート 本日、コストエクスプローラーに新しいリザーブドインスタンス使用率レポートが追加されます。リンクされたアカウント間で分散された数千のサブスクリプションにユーザーが増えても、組織全体にわたり RI 全体の使用率を追跡し、管理する機能が得られます。また、1 年前まで遡って、使用率全体または個別の RI の使用率を確認することもできます。さらに、1 年前まで遡って、使用率全体または個別の RI の使用率を確認し、RI 使用率のしきい値を定義して、それに対する実際の使用率をモニタリングすることもできます。事前に定義されたターゲットを使用率が下回っている RI サブスクリプションが見つかった場合、ドリルダウンしてアカウントの所有者、インスタンスタイプ、および未使用の時間を確認できます。また、コストエクスプローラーで提供される既存のフィルタリング関数にすべてアクセスできます。私は数千のリザーブドインスタンスを所有していないので、サンプルのスクリーンショットとテストデータを使って、このレポートの外観と使用方法を示します。新しいレポートはコストエクスプローラーのメニューから日次または月次で利用できます (このメニューには、私が定義した 3 つのレポートが含まれています)。 RI 使用率の日次レポートを次に示します。 RI は RI 使用率の降順に表示されています。デフォルトでは、最も使用されていない RI がリストの先頭に表示されます。クリックすると、時間の経過に伴う使用率と、RI に関する詳細情報が表示されます。 特定の RI に注目するため、インスタンスタイプまたはその他の属性別にフィルタできます。 必要な時間範囲も設定できます。インスタンスタイプでフィルタして時間範囲を設定することで、先月に d2.8xlarge RI を十分に活用したことを次のように確認できます。 使用率ターゲットを目的の割合に設定でき、それが基準線としてグラフに表示されます。ここでは、6 月に使用率が 80% […]