Amazon Web Services ブログ

Tag: Compute

VMware Cloud on AWSを使用した複数のディザスタリカバリSLAへの対応

AWSでPartner Solutions Architectを務めるKiran Reid、VMwareでTechnical Marketing Architectを務めるMike McLaughlin氏による記事です。 以前のブログでVMware Cloud on AWSを利用したディザスタリカバリ(DR)の設計上の考慮点について説明し、VMwareが提供するDisaster Recovery as a Service(DRaaS)オファリングであるVMware Site RecoveryとVMware Cloud Disaster Recoveryを紹介いたしました。 本稿では、これら2つのオファリングについて、そしてそれらをどちらか一方、または両方デプロイして、より堅牢なDRをVMware Cloud on AWSに導入できる可能性に焦点を当てます。どちらのアプローチも、個々のビジネス要件を満たす為に、複数のサービスレベルアグリーメント(SLA)とサービスレベル目標(SLO)に対処するのに役立ちます。

Read More
VMware Cloud on AWS

VMware Cloud on AWS で実現するマイクロサービスアーキテクチャとモダンアプリケーション

AWS で Sr. Specialist Solution Architect を務める Sheng Chen による記事です。 VMware Cloud on AWS は、Amazon Web Services (AWS) グローバルインフラストラクチャ上で、 VMware Software-Defined Data Center (SDDC) を展開し、 vSphere ワークロードを実行するための柔軟でスケーラブルなソリューションを提供します。 200 以上の AWS ネイティブ サービスとの統合アクセスにより、VMware Cloud on AWS は、お客様がビジネスの中断を最小限に抑えつつ、アプリケーションのモダナイゼーションジャーニーを加速するのに役立ちます。 具体的には、VMware Cloud on AWS と AWS サービス統合するための独自の機能を利用することで、お客様はアプリケーションの変革とマイクロサービス アーキテクチャへの移行を開始することができます。

Read More

EKS と Fargate、AWS Compute Savings Plans で Pod の料金を節約する

この記事は、Saving money a pod at a time with EKS, Fargate, and AWS Compute Savings Plans を翻訳したものです。 re:Invent 2019 では、Amazon Elastic Kubernetes Service (Amazon EKS) で、Kubernetes の Pod を AWS Fargate にデプロイできるようになったことが発表されました。その発表以降、多くのお客様が実際に Fargate 、つまりコンテナを実行するためのサーバーレスインフラストラクチャーに Kubernetes の Pod をデプロイしています。Fargate を利用することで、クラスターの管理やパッチの適用、セキュリティやアイソレーション、スケーリングといった様々な運用業務、「差別化にならない重労働( undifferentiated heavy lifting )」から解放されます。 Amazon EKS と Fargate の詳細については、re:Invent のブレイクアウトセッションでも掘り下げられています。 AWS Fargate は AWS Compute Savings Plans […]

Read More

より低コストで高い性能を実現:SQL ServerのコストパフォーマンスでAWSがAzureを上回る

このブログでは、2021年2月25日にPrincipled Technologies社により発行されたベンチマーク資料をレビューしていきたいと思います。このベンチマークによると、同じSQL Serverワークロードを稼働させる上で、Amazon Elastic Compute Cloud(Amazon EC2)のR5b.8xlargeインスタンスがAzure E64_32s_v4 VMよりも低いコストで高い性能を発揮しています。
AWSはWindowsワークロード向けに優れたコストパフォーマンスを提供するだけでなく、クラウド上でWindowsを稼働させるより良い方法をご用意しています。既存のデータベースをEC2にリホストするにも、Amazon Relational Database for SQL Server(RDS)を利用しマネージドサービスに移行するにも、またはクラウドネイティブなデータベースにモダン化するにも、AWSはお客様がクラウドを最大限ご活用いただけるよう必要なサービスを揃えてお待ちしています。

Read More

アップデート — EC2 Auto Scalingのキャパシティリバランシング機能によるスポットインスタンスの事前置き換え

本記事は、EC2プロダクトサービスチームのDeepthi ChelupatiとChad Schmutzerによる寄稿です。 本日より、Amazon EC2 Auto Scaling のキャパシティリバランシング機能を提供するようになりました。これは、Auto Scaling グループで Amazon EC2 スポットインスタンスのライフサイクルをプロアクティブに管理するための新機能です。キャパシティリバランシングは、最も余裕のある空きキャパシティを自動的に選択する capacity-optimized 配分戦略 (英語記事)と、複数のアベイラビリティーゾーンにまたがって複数のインスタンスタイプを活用できるミックスインスタンスポリシー機能を補完する位置付けの機能です。キャパシティリバランシングは、スポットインスタンスが Amazon EC2 サービスによって中断される前に、 Auto Scaling グループのスポットインスタンスを自動的に置き換えます。これにより、お使いの Auto Scaling グループの可用性をより一層高めることができます。 スポットインスタンスの事前置き換えを実現するため、キャパシティリバランシングは EC2 サービスの新機能である、 EC2 インスタンスのリバランス通知を活用します。これは、スポットインスタンスが中断のリスクが高まった際に送信されるシグナルです。リバランス通知は、これまで提供してきた 2 分前のスポットインスタンス中断通知よりも早く提供されることが期待されるため、来たる中断に備え、ワークロードをプロアクティブにリバランスする機会を提供します。 EC2 Auto Scaling のキャパシティリバランシングは、スポットインスタンスのライフサイクルを踏まえ、その時点で必要な希望容量を維持するためのシームレスで自動化された仕組みを提供します。これには、リバランス通知の監視、また中断のリスクが高い場合の代替キャパシティーの事前起動、さらに必要に応じて Elastic Load Balancing からのデタッチや、設定されたライフサイクルフックの実行が含まれます。この記事では、スポットインスタンスを中心としたワークロードに対して、EC2 Auto Scaling でキャパシティリバランシングを使用して Auto Scaling グループを管理する方法の概要を説明し、お使いの環境でキャパシティリバランシングを活用するためのユースケースの例を紹介します。 EC2 Auto Scaling と スポットインスタンス — これまでのおはなし さてここで、スポットインスタンスが何であるか、また EC2 […]

Read More
Lambda Thumb

新機能 – Lambda関数の共有ファイルシステム – Amazon Elastic File System for AWS Lambda

本投稿は AWS の Chief Evangelist (EMEA)であるDanilo Pocciaによる寄稿です。 AWS Lambda関数がAmazon Elastic File System(EFS)をマウントできるようになったことを非常に嬉しく思います。EFSは、高可用性と耐久性のために複数のアベイラビリティーゾーン(AZ)にまたがってデータを格納するスケーラブルでエラスティックなNFSファイルシステムです。このように、使い慣れたファイルシステムインターフェイスを使用して、関数単体、および複数のLambda関数のすべての同時実行環境にわたってデータを保存および共有できます。 EFSは、強力な整合性やファイルロックなどの完全なファイルシステムアクセスセマンティクスをサポートしています。 Lambda関数を使用してEFSファイルシステムを接続するには、EFSアクセスポイントを使用します。これは、ファイルシステムへのアクセス時に使用するオペレーティングシステムのユーザーとグループを含むEFSファイルシステムへのアプリケーション固有のエントリポイント、ファイルシステムのアクセス許可、およびファイルシステム内の特定のパスへのアクセスを制限できます。これにより、ファイルシステム構成をアプリケーションコードから切り離しておくことができます。 同一のアクセスポイント、または異なるアクセスポイントを使用して、複数の関数から同じEFSファイルシステムにアクセスできます。たとえば、異なるEFSアクセスポイントを使用して、各Lambda関数はファイルシステムの異なるパスにアクセスしたり、異なるファイルシステムのアクセス許可を使用したりできます。 同じEFSをAmazon Elastic Compute Cloud(EC2)インスタンス、Amazon ECSとAWS Fargateを使用するコンテナ化されたアプリケーションや、オンプレミスサーバーと共有できます。このアプローチに従って、異なるコンピューティングアーキテクチャ(関数、コンテナ、仮想サーバー)を使用して同じファイルを処理できます。たとえば、イベントに反応するLambda関数は、コンテナで実行されているアプリケーションによって読み取られる構成ファイルを更新できます。または、Lambda関数を使用して、EC2で実行されているWebアプリケーションによってアップロードされたファイルを処理できます。 このようにすると、いくつかのユースケースではLambda関数によって実装がより容易になります。例えば: /tmpで使用可能な容量(512MB)より大きいデータを処理またはロードする。 頻繁に変更されるファイルの最新バージョンをロードする。 モデルやその他の依存関係をロードするためにストレージ容量を必要とするデータサイエンスパッケージを使用する。 呼び出し間で関数の状態を保存する(一意のファイル名またはファイルシステムロックを使用)。 大量の参照データへのアクセスを必要とするアプリケーションの構築。 レガシーアプリケーションをサーバーレスアーキテクチャに移行する。 ファイルシステムアクセス用に設計されたデータ集約型ワークロードとの相互作用。 ファイルを部分的に更新する(同時アクセス用のファイルシステムロックを使用)。 アトミック操作でファイルシステム内のディレクトリとそのすべてのコンテンツを移動する。 EFSの作成 EFSをマウントするには、Lambda関数がEFSマウントターゲットに到達できるAmazon Virtual Private Cloud(VPC)に接続されている必要があります。ここでは、簡単にするために、各AWSリージョンで自動的に作成されるデフォルトのVPC を使用しています。 Lambda関数をVPCに接続する構成にすると、ネットワーク環境の変化に伴う変更が必要になることがある点に注意してください。 Lambda関数がAmazon Simple Storage Service(S3)またはAmazon DynamoDBを使用している場合は、それらのサービスのゲートウェイVPCエンドポイントを作成する必要があります。 Lambda関数がパブリックインターネットにアクセスする必要がある場合、たとえば外部APIを呼び出す場合は、NATゲートウェイを構成する必要があります。通常、デフォルトVPCの構成は変更しません。特定の要件がある場合は、AWS Cloud Development Kitを使用してプライベートおよびパブリックサブネットで新しいVPCを作成するか、これらのAWS CloudFormationのサンプルテンプレートのいずれかを使用します。このようにすることで、ネットワークをコードとして管理できます。 EFSコンソールで、[Create file system]を選択し、default のVPCとそのサブネットが選択されていることを確認します。すべてのサブネットで、同じセキュリティグループを使用してVPC内の他のリソースへのネットワークアクセスを提供するデフォルトのセキュリティグループを使用します。 次のステップでは、ファイルシステムにNameタグを付け、他のすべてのオプションをデフォルト値のままにします。 次に、[Add access […]

Read More

Lambda@Edge デザインベストプラクティス

Lambda@Edge をより活用いただくために Lambda@Edge ベストプラクティスシリーズと題したブログを連載します。この中ではいくつかのユースケースを用いて Lambda@Edge をどのように利用すればよいか、CI/CD パイプラインにどのように組み込むべきか、ビジネスニーズに応える形で組み込まれていることを担保するためにはどのように考えればよいか等について取り上げます。 記念すべき初回は Lambda@Edge のデザインベストプラクティスについて取り上げます。いくつか一般的なユースケースをもとに関数をどのタイミングで実行するのが良いのか、それはどのような観点で選択されるべきかということについてパフォーマンス及びコスト最適化の観点から推奨構成について説明していきたいと思います。

Read More