Category: Compute

AWS App Meshは、AWS上のマイクロサービスアプリケーション間の通信を簡単に監視、制御できるサービスメッシュです。 Amazon Elastic Container Service (Amazon ECS)やAmazon Elastic Container Service for Kubernetes (Amazon EKS)、Amazon EC2上で稼働するKubernetesで動作するマイクロサービスとあわせてApp Meshを使用できます。 今日からApp Meshはpublic previewとして利用できます。数ヶ月後に、新しい機能とインテグレーションを追加する計画です。 なぜApp Meshなのか？ 多くのお客様はマイクロサービスアーキテクチャでアプリケーションを構成しており、アプリケーションを多数の、独立してデプロイされ、操作される多数の別々の小さなソフトウエア群に分割しています。各コンポーネントが需要に応じて個別にスケールすることにより、マイクロサービスはアプリケーションの可用性とスケーラビリティを向上させます。各マイクロサービスはAPIを通じて他のマイクロサービスと相互に作用します。

ソフトウェア開発者には好みの開発ツールというものがあります。パワフルなエディタを使う人もいれば、特定の言語やプラットフォームに最適化された統合開発環境（IDE）を使う人もいます。AWS Lambda のコンソールのエディタを使って、2014年に私は初めての AWS Lambda 関数を作りました。現在では、サーバーレス・アプリケーションをビルドしデプロイするためのツールの選択肢は豊富になりました。例えば、昨年 AWS Cloud9 がリリースされて AWS Lambda のコンソールのエディタ環境は大きく強化されました。.NET アプリケーションでは、 AWS Toolkit for Visual Studio と AWS Tools for Visual Studio Team Services を使う事ができます。 AWS Toolkits for PyCharm、IntelliJ（プレビュー）、そして Visual Studio Code（プレビュー） 今日、 AWS Toolkit for PyCharm の一般提供をお知らせします。また、 AWS Toolkits for IntelliJ と Visual Studio Code の開発者プレビューをお知らせします。これら（AWS Toolkits for IntelliJ と Visual Studio […]

私は2014年にアナウンスしたAWS Lambdaを発表した興奮を覚えています。4年の間でお客様は様々な異なるユースケースでLambda関数をご利用頂いています。 例をあげると iRobotはAWS Lambdaをロボット掃除機のroombaのコンピュートサービスとして利用しています、Fanne MaeはMonte Carloの100万をこえる抵当のシミュレーションとして利用、Bustleは彼らのデジタルコンテンツへの数百万のリクエストとして利用しています。本日、私は2つの新しい機能をご紹介します、これは今までよりサーバレスの開発を簡単にするものです： Lambda Layers, 複数の関数で共用されるコードやデータをセンタライズし管理するものです Lambda Runtime API, あなたが開発する、どんなプログラム言語や特定のバージョンでも簡単に利用できるようになるものです これら2つの機能は一緒に利用することができます。ランタイムはレイヤとして共有できるために、開発者はLambda関数を作成時にお好みの言語で利用することができます。

アプリケーションをマイクロサービス(多数の別れたサービスがそれぞれ1つのジョブを実行する)として構成するお客様が増えています。マイクロサービスによりお客様は、多くの場合で反復的かつ、より素早いデプロイを可能になります。これらのマイクロサービスをベースとしたモダンなアプリケーションの多くは、様々な種類のクラウドリソースを利用して構成され、動的に変更されるインフラストラクチャ上にデプロイされます。これまでは、アプリケーションリソースの場所を管理するために設定ファイルを利用する必要がありました。しかし、マイクロサービスをベースとしたアプリケーションにおける依存関係は簡単に管理するには、複雑すぎる様になります。加えて、多数のアプリケーションは動的にスケールし、トラフィックにあわせて変更されるコンテナを利用して構成されていています。その様な構成はアプリケーションの応答性を向上させますが、新しい問題をもたらします。- 現在、アプリケーションのコンポーネントはその動作時にアップストリームサービスを検出し、接続する必要があります。この動的に変更されるインフラストラクチャーおよびマイクロサービスにおける接続性に関する問題は、共通してサービスディスカバリーによって解決されます。

BYOL（Bring Your Own License）を使用してAWSクラウドで商用ライセンスソフトウェアを使用する場合、不必要なライセンス調達を避けつつ、ライセンス条項の範囲内に収まるように展開を管理する必要があります。必要に応じてオンデマンドでインスタンスを起動したい場合、これは難しい課題です。 新サービス “AWS License Manager” 2018年11月28日、AWS License Managerをローンチしました。このサービスはライセンスルールを定義して、その中にエンタープライズ契約やライセンスされたソフトウェアの使用に適用されるその他の条件を考慮に入れるよう設定することができます。そして、定義したルールは展開メカニズム（ゴールデンAMIまたは起動テンプレート）に関連付けることができます。ルールが適用され起動されたEC2インスタンスは自動的に追跡されます。 また、1つまたは複数のAWSアカウントで使用状況を検出し、AWS管理コンソールからすべての使用状況を追跡することもできます。 それでは簡単に機能を見ていきましょう。ここでは、エンタープライズデータベース用のvCPUライセンスを100持っていると仮定します。 最初のステップは、1つ以上のライセンス設定を定義することです。 ライセンスマネージャコンソールを開き、[Create license configuration]をクリックして開始します: 構成の名前と説明を入力し、ライセンスがvCPUに基づいており(最大100に制限されています)、ライセンス数を限定強制したい事が示されます(Enforce license limit チェックボックスをオン)： また、新たなライセンスルールを作成することもできます。 ルールは、EC2の構成に対するライセンスの適用可否を制御します。 vCPUの最小数や最大数、EC2テナントタイプ (共有、専有インスタンス、Dedicated Host) を指定できます。 例えば 4～64のvCPUと共有テナントを指定するルールは次のようになります： ルールが正しく定義されていることを確認し、Submitをクリックして次に進みます。 これで、ライセンスルールは準備が整いました。この画面ではルールの一覧が表示されており、私が作成したものと、他の人が作成したものも見る事が出来ます： ライセンスルールを作成したら、ルールを選択して[Actions]メニューの[Associate AMI]をクリックしてAMIと関連付けることができます。 1つ以上のAMIを選択し[Associate]をクリックします： 全体的なライセンスの使用状況を一目で確認できます（これは、複数のアカウントとAWS Organizationsと連携して機能するセントラルダッシュボード画面です）： [Settings]をクリックして自分のAWS Organizationsアカウントにリンクし、クロスアカウントインベントリ検索を設定してライセンスの使用制限を逸脱したとき、SNSアラートを受信するように設定することも出来ます： その他 ここではAWS License Managerについてその他のいくつか知っておくべきことについて触れます： サポートされるライセンスタイプ – AWS License ManagerはvCPU、物理コア、物理ソケットをベースとしたライセンスをサポートします。特定のソフトウェアベンダーに紐づくものではありません。 クロスアカウントの使用管理 – AWS License Managerは、AWS Organizationsと組み合わせて使用する事が可能です。 マスターアカウントに署名した全てのアカウントでリンクし、組織全体でライセンス設定を共有することができます。 ダッシュボードを使用して、組織全体のライセンス使用状況を確認することができます。 […]

クラウド上で Windows アプリケーションを利用しようとしている組織では、通常、既存のアプリケーションや Windows 環境と完全に互換性のあるネットワークストレージを探します。例えば、エンタープライズ企業では ID 管理目的で Active Directory を使用し、フォルダやファイルへのきめ細かなアクセス制御のために Windows Access Control List を使用し、これらの企業のアプリケーションは Windows ファイルシステム (NTFS ファイルシステム) と完全互換のストレージに頼った作りになっています。 Amazon FSx for Windows ファイルサーバー Amazon FSx for Windows ファイルサーバーはこれら全てのニーズに対応しています。既存の Windows アプリケーションや Windows 環境で作業することを前提に設計されており、Windows ワークロードのクラウドへの Lift-and-Shift を非常に簡単にしてくれます。完全マネージド型の Windows ファイルサーバーに裏付けられたネイティブ Windows ファイルサーバーに、広く採用されている SMB (Server Message Block) プロトコルを介してアクセスできます。SSD ストレージで構築されている Amazon FSx for Windows ファイルサーバーは、皆さん (と皆さんの Windows アプリケーション) […]

AWS Fargate と Amazon Elastic Container Service (Amazon ECS) 上で稼働するサービスでの Blue/Green デプロイメントがサポートされます。 AWS CodeDeploy を利用し、 Blue/Green デプロイメントを行うことでアプリケーションの更新時のダウンタイムを最小限に抑えることが出来るようになります。 Blue/Green デプロイメントは、古いバージョンと新しいバージョンのアプリケーションを同時に起動し、新しいバージョンをテストしてからトラフィックをルーティングします。デプロイ状況を監視し、問題が発生した場合はすぐにロールバックすることも出来ます。 この新しい機能により、デプロイメント、テスト、トラフィックのカットオーバーが管理されたサービスを、AWS Fargate または Amazon ECS で作成することが出来ます。 サービスを更新すると、AWS CodeDeploy によってデプロイメントがトリガーされます。 このデプロイメントは、Amazon ECSと連携して、新しいバージョンのサービスを Green 環境用のターゲットグループにデプロイし、ロードバランサのリスナーを更新してこの新しいバージョンをテストできるようにし、ヘルスチェックが成功した場合にカットオーバーを実行します。

本日(11/28)、Amazon Elastic Container Registry (Amazon ECR) を AWS CodePipline のソースプロバイダとして利用可能になりました。これにより Amazon ECR に新しいイメージをアップロードすることにより、AWS CodePipelineを起動することができるようになります。AWS Developer Tools による CI/CD 実現が一段と容易になりました。 Amazon ECR をソースとして使うには、AWS CodePipline コンソールでAWS CodeDeploy による Blue/Green デプロイメントを実装している必要があります。CodePipelineを使わず、Amazon Elastic Container Service (Amazon ECS) コンソールを使って Blue/Green デプロイメントを実装するより詳しい情報については、AWS CodeDeploy による AWS Fargate と Amazon ECS でのBlue/Greenデプロイメントの実装を参照してください。 この投稿では Amazon ECR とAWS CodePipeline を使用してエンドツーエンドの継続的デリバリ (CD) パイプラインを構築する方法について解説します。ここではアップストリームのベースイメージが更新されたらコンテナイメージを更新ためのパイプラインを作る一連の流れを説明します。

私の好きなAmazonリーダーシッププリンシプルの1つはCustomer Obsessionです。 私たちがAWS Lambdaをローンチしたとき、私たちは開発者にセキュアなサーバーレス体験を提供し、インフラストラクチャの管理を避けることに重点を置いていました。 目的のレベルの分離を達成するために、我々は各顧客に専用のEC2インスタンスを使用しました。 このアプローチにより、私たちはセキュリティ目標を達成することができましたが、私たちがLambdaを裏で管理する方法に関していくつかのトレードオフを余儀なくされました。 また、新しいAWSサービスの場合と同様に、顧客がLambdaをどのように使用するのか、あるいはサーバーレスモデル全体をどのように考えているのかもわかりませんでした。 私たちの計画は、時間の経過とともにバックエンドをより効率的にすると同時に、優れたカスタマーエクスペリエンスを提供することに重点を置くことでした。 ちょうど4年後 (Lambdaはre:Invent 2014でローンチされました)、サーバーレスモデルが普及したことは明らかです。 現在Lambdaは毎月何十万人ものアクティブな顧客に対して数兆件の処理を実行しています。 昨年、我々はAWS Fargateのローンチによりサーバーレスの利点をコンテナにまで拡張し、毎週AWSの顧客に数千万のコンテナを提供しています。 私たちの顧客がサーバーレスでの採用を進める中で、効率の問題を再検討する時が来ました。 Invent and Simplifyの原則を念頭に置いて、今のコンテナやファンクションの世界のための設計として仮想マシンがどのように見えるのか自分自身に尋ねました。 Firecrackerの紹介 本日、KVMを利用する新しい仮想化技術であるFirecrackerについてお話したいと思います。 仮想化されていない環境では、軽量のマイクロ仮想マシン（microVM）を数秒で起動することができ、従来のVMで提供されているセキュリティとワークロードの分離と、コンテナに伴うリソース効率性を向上しています。 Firecrackerについて知っておくべきことは次のとおりです: セキュア – これは常に最優先事項です! Firecrackerは複数レベルの分離と保護を使用し、攻撃面は最小限に抑えられています。 ハイパフォーマンス – 今日時点でわずか125ミリ秒 (さらに2019年に高速化予定) でmicroVMを立ち上げることができ、一時的なものや短命のものを含む多くの種類のワークロードに最適です。 Battle-Tested – FirecrackerはBattle-Testedであり、既にAWS LambdaとAWS Fargateを含む複数のハイボリュームなAWSサービスに利用されています。 低オーバーヘッド – Firecrackerは、microVMあたり約5 MiBのメモリを消費します。 同じインスタンス上で、さまざまなvCPUとメモリ構成を持つ数千のセキュアなVMを実行できます。 オープンソース – Firecrackerはアクティブなオープンソースプロジェクトです。私たちはすでにpullリクエストを確認して受け入れる準備を完了しており、世界中の寄稿者とのコラボレーションを楽しみにしています。 Firecrackerは最小限主義の流儀で造られました。 私たちはオーバーヘッドを減らし安全なマルチテナンシーを可能にするために、crosvmからスタートし、最小限のデバイスモデルを設定しました。 FirecrackerはRustで書かれており、その最新のプログラミング言語はスレッドの安全性を保証し、セキュリティの脆弱性を引き起こす可能性があるさまざまなタイプのバッファオーバーランエラーを防止します。 Firecrackerのセキュリティ 前述のように、Firecrackerには多数のセキュリティ機能が組み込まれています! ここに部分的なリストがあります: Simple Guest Model – Firecrackerのゲストには、ネットワークデバイス、ブロックI […]

私たちは昨年、強力なコンピューティング集約型のC5インスタンスを立ち上げ、今年初めにはローカルNVMeストレージを追加したC5dインスタンスをフォローアップしました。 どちらのインスタンスもAWS Nitroシステム上に構築されており、AWSカスタムの3.0Ghz Intel Xeon Platinum 8000シリーズプロセッサを搭載しています。 それはバッチ処理、分散解析、ハイパフォーマンスコンピューティング(HPC)、広告配信、ハイスケーラブルなマルチプレーヤゲーミング、ビデオエンコーディングなどのコンピューティング重視のアプリケーション用に設計されています。 新しい100 Gbpsのネットワーク 本日私たちはさらに強力な変種であるC5nのインスタンスを追加しました。 最大100 Gbpsのネットワーク帯域幅で、シミュレーション、インメモリキャッシュ、データレイク、その他の通信集約型アプリケーションがこれまで以上に優れたパフォーマンスを発揮します。 スペックは以下の通りです： Instance Name vCPUs RAM EBS Bandwidth Network Bandwidth c5n.large 2 5.25 GiB Up to 3.5 Gbps Up to 25 Gbps c5n.xlarge 4 10.5 GiB Up to 3.5 Gbps Up to 25 Gbps c5n.2xlarge 8 21 GiB Up to 3.5 Gbps Up […]