Amazon Web Services ブログ

本日、AWS Fargate の新しいプラットフォームバージョン (1.4) をリリースしました。これには、お客様のための数多くの新しい機能が含まれています。これらの機能の詳細については、こちらのブログ記事をご覧ください。プラットフォームバージョン 1.4 で導入された変更点の 1 つは、Fargate のコンテナ実行エンジンとして、Docker Engine を Containerd に置き換えたことです。  このブログ記事では、お客様のコンテナのワークロードにとってこれが何を意味するか、この変更の背後にある動機、およびこの再設計されたコンテナ実行環境 (Fargate データプレーンとも呼ばれます) の内情について詳しく説明します。 用語集 ブログの本編で使用する用語と概念を確認してみましょう。 コンテナランタイム/実行エンジン: これは、コンテナの作成、起動、停止に使用するソフトウェアの一部で、一般的には「コンテナランタイム」とも呼ばれます。それには、たとえば、Docker Engine、Containerd、CRI-O などがあります。 runC: これは、Open Containers Initiative (OCI) ランタイム仕様に基づいてコンテナを生成および実行するためのツールです。 Containerd: これは、通常 runC を使用して、ホスト上のコンテナのライフサイクルを管理するデーモンです。runC と Containerd がどのように相互に作用するかの詳細については、Michael Crosby のブログ記事をご覧ください。 Docker Engine: Docker が提供するコンテナエンジン。通常、これには、コンテナを実行する必要があるホストにインストールする必要がある Docker デーモンバイナリが含まれます。Docker Engine は、runC の上に構築される Containerd に構築されます。 Containerd への切り替えは、Fargate で実行されているコンテナにとってどのような意味があるのか? 端的に言うと、この切り替えにより、ワークロードに何も影響はありません。 Fargate […]

AWS Fargate は、コンテナを実行するためのマネージドサービスです。Fargate を使用すると、Amazon Elastic Container Service (ECS) と Amazon Elastic Kubernetes Service (EKS) を使用して、インフラストラクチャの保守、パッチ適用、スケーリング、セキュリティ保護、ライフサイクルなどの未分化の重労働に対処する負担なしに、アプリケーションを起動できます。Amazon EC2 はお客様のハイパーバイザーと物理サーバーを抽象化しますが、AWS Fargate はコンテナランタイムと EC2 インスタンスに対して同じことを行います。コンテナの世界で Fargate が果たす役割について詳しく知りたい場合は、こちらのブログ記事をご覧ください。 Fargate は、お客様がインフラストラクチャについて考える必要がないという意味でインフラストラクチャを非表示にしますが、インフラストラクチャはまだ存在し、AWS が管理しています。今もインフラストラクチャ機能がエンドユーザーに表示されるのは、Fargate プラットフォームバージョンの概念によるものです。詳細については、Fargate のドキュメントをご覧いただくか、Fargate プラットフォームバージョンの入門のブログ記事をご覧ください。 入門のブログ記事では、Fargate プラットフォームバージョンを導入した理由と、たとえば、プラットフォームバージョン 1.4.0 をまだ「LATEST」のものとしてタグ付けしていない実務上の理由について詳しく説明しています。 本日、AWS Fargate のプラットフォームバージョン 1.4.0 をリリースします。 このブログ記事では、今回のリリースで有効にした Fargate 機能の概要と、その中で行った変更の一端をご紹介します。これらの根本的な変更は、必ずしもお客様に表示される新しい機能と直接的な関係があるとは限りませんが、同じくらい重要です。 Fargate プラットフォームバージョン 1.4.0 の新機能 プラットフォームバージョン 1.4.0 では、AWS Fargate の新機能がいくつか導入されています。ブログ記事のこのセクションでその新機能について説明します。 特に明記されていない限り、このブログ記事で説明されている新機能は、ネイティブの Fargate プラットフォームに関連するもので、ECS オーケストレーターで直接利用できます。コンテナの世界で Fargate が果たす役割、特に […]

AWS Fargate は、コンテナを実行するためのマネージドサービスです。これは AWS のマネージドサービスの 1 つで、ユーザーはその中のインフラストラクチャを気にすることなくコンテナを起動できます。別のブログ記事では、AWS Fargate プラットフォームバージョン 1.4.0 で導入した新機能と変更点について詳しく説明しました。一歩下がって、Fargate プラットフォームのバージョンについてもっと全体的な話をしましょう。 ご存知のように、コンテナとコンテナランタイム (Containerd など) の全体的な目的は、コンテナイメージ (ユーザーが提供するもの) を、そのイメージを起動する予定の (AWS Fargate が提供する) オペレーティングシステムから切り離すことです。ただし、これは明確な分離ではなく、これらの 2 つのレイヤーは抽象化の一部をリークしてしまう可能性があります。 リークする抽象化レイヤーは、この業界では新しい出来事ではありません。これは、下のレイヤーで同じデカップリングの目的を果たすハイパーバイザーと VM ではそれほど問題ではありません。とはいえ、これらの 2 つのレイヤー間のインターフェイスは十分に確立されており、相互にリークする可能性は低くても、一方のレイヤーが他方のレイヤーの変更を認識しなければならない状況がありました。たとえば、標準の EC2 インスタンスから Nitro ベースの EC2 インスタンスへの移行と、これが AMI に及ぼす影響について考えてみてください。たとえば、Nitro ベースのインスタンスタイプを使用するには、ドキュメントに記載されているように、AMI に特定のネットワークドライバーを含める必要があります。 上記のため、AWS Fargate で実行されているコンテナに公開しているインターフェイスをより強力に制御する必要がありました。ここで Fargate プラットフォームのバージョンが登場しました。特定のプラットフォームバージョンを選択してそれに固執することにより、開発者は、基盤となるインフラストラクチャとサポートソフトウェアが変更されないようにし、スタック全体で高い忠実度を維持し、抽象化を変更するリスクを軽減できます。 プラットフォームバージョン 1.3.0 をほぼ 1 年前にリリースして以来、かなりの数の新機能を導入してきました。プラットフォームバージョン 1.4.0 の変更点が機能しなくなるとは思いませんが、それが非常に重要な変更であるため、プラットフォームバージョン 1.3.0 に戻ることができる可能性を残しておく方が、新しいプラットフォームバージョンがユーザーにとってより優れたランウェイとなり、採用するリスクが低くなるだろうと判断しました。 Fargate プラットフォームバージョンの消費の基本 […]

Jeff がこのブログで Amazon Elastic Container Service の開始について書いてから 5 年になります。私はその記事を読んで、エキゾチックで珍しいコンテナがどのように聞こえるかについて考えたことを覚えています。わずか 5 年後まで話を進めると、コンテナはほとんどの開発者にとって日常生活の一部になっていることでしょう。しかし、お客様が ECS などのコンテナオーケストレーターをますます採用している一方で、このコンテナ化された世界への移行が難しいアプリケーションの種類もまだあります。 コンテナは本来一時的なものであるため、データの永続化または共有ストレージを必要とするアプリケーションを構築しているお客様は、課題に直面しています。コンテナは動的にスケールインおよびスケールアウトされるため、ローカルデータはコンテナが終了すると失われます。本日、Amazon Elastic File System (EFS) ファイルシステムのサポートを開始することにより、ECS 用に変更しようと思います。ECS および AWS Fargate で実行されている両方のコンテナ Amazon Elastic File System (EFS) を使用できます。 この新機能は、コンテンツ管理システム、内部 DevOps ツール、機械学習フレームワークなどの共有ストレージを必要とするアプリケーションをコンテナ化するのに役立ちます。真新しい一連のワークロードではコンテナがもたらすメリットを享受できるようになり、お客様はデプロイプロセスの高速化、インフラストラクチャー利用の最適化、および回復力のあるシステムの構築を可能にします。 Amazon Elastic File System (EFS) は、フルマネージド、高可用性、スケーラブルな共有ファイルシステムを提供します。これにより、コンピューティングとは別にデータを保存できます。これはリージョンサービスでもあります。サービスは 3 つのアベイラビリティーゾーン内およびアベイラビリティーゾーン間でデータを格納し、高可用性と耐久性を実現します。 これまでは、EC2 インスタンスのクラスターでコンテナを実行している場合、ECS で EFS を機能させることが可能でした。ただし、AWS Fargate をコンテナデータプレーンとして使用する場合、この発表を行う以前は EFS ファイルシステムをマウントできませんでした。Fargate では、お客様が Fargate フリート内のマネージドインスタンスにアクセスすることを許可していないため、EFS をセットアップするためにインスタンスに必要な変更を加えることができません。 EFS […]

Amazon RDS for SQL Server は、リージョン内のリードレプリカをサポートするようになりました。これにより、読み取りワークロードをプライマリデータベースインスタンスからレプリカにオフロードできます。リードレプリカは内蔵の分散型可用性グループ機能を使用しており、Enterprise Edition でご利用いただけます。分散型可用性グループは、2 つの別個の可用性グループにまたがる可用性グループです。分散型可用性グループのメンバーは、それ自体が可用性グループです。Amazon RDS は、このアーキテクチャに、ドメインに依存しない Windows Server Failover Cluster (WSFC) を使用します。この記事では、リードレプリカのアーキテクチャ、リードレプリカの作成方法、およびそれをモニタリングする方法について説明します。 リードレプリカは、SQL Server 2016 Service Pack 2 Cumulative Update 3 (13.00.5216.0.v1) 以降のマルチ AZ 設定の Enterprise Edition でサポートされています。 リードレプリカのマルチ AZ 設定 リードレプリカのマルチ AZ 設定では、プライマリ DB インスタンスでコミットされたトランザクションは、高可用性を目的として同期的にセカンダリレプリカにレプリケートされ、読み取りのスケールアウトのためにリードレプリカに非同期的に送信されます。リードレプリカには、プライマリ DB インスタンスからのほぼリアルタイムのデータが含まれており、それらを使用して、読み取り専用ワークロードをプライマリ DB インスタンスからオフロードできます。そのワークロードには、たとえば、データ更新のレイテンシーをある程度許容できる分析タイプまたはレポートタイプのクエリがあります。さらに、リードレプリカをプライマリまたはセカンダリ DB インスタンスとは異なるアベイラビリティーゾーンでウォームスタンバイソリューションとして使用でき、ビジネスニーズに基づいてレプリカをシングル AZ インスタンスに昇格できます。Transparent Data Encryption (TDE) または AWS KMS […]

グラフアプリケーションを構築する場合、Apache TinkerPop または RDF/SPARQL グラフアプリケーションを構築するために反復する際、高速で費用効果の高いインスタンスが必要です。Amazon Neptune では、固定パフォーマンスインスタンス (R5 および R4) に加えて、バースト可能なパフォーマンスインスタンス (T3) を選択できるようになりました。Amazon Neptune db.t3.medium のバースト可能なパフォーマンスインスタンスは、このようなユースケース用に特別に設計されており、最小の固定パフォーマンスインスタンスよりも 76% 低い料金でご利用いただけます。本番環境に入る準備ができているか、データベースの本番環境ワークロードで常に高い CPU パフォーマンスが必要な場合は、AWS マネジメントコンソール、AWS SDK、または AWS CLI を使って、固定パフォーマンスインスタンスを既存のクラスターにすばやく追加できます。 この記事では、Amazon Neptune T3 バースト可能なパフォーマンスインスタンスと、このインスタンスタイプでデータベースクラスターを作成する方法について説明します。 バースト可能なパフォーマンスインスタンスについて バースト可能なパフォーマンスインスタンスは、ベースラインレベルの CPU パフォーマンスを提供し、ベースラインを超えてバーストする機能を備えています。Neptune T3 インスタンスは、ワークロードが必要とする限り、高い CPU パフォーマンスを維持できます。ほとんどの開発およびテストワークロードでは、T3 インスタンスは低コストで優れたパフォーマンスを実現します。T3 インスタンスの平均 CPU 使用率が、24 時間を超えてベースラインよりも低い場合は、T3 インスタンスの時間料金で使用時のすべての一時的なスパイクがカバーされます。 T3 インスタンスのベースラインパフォーマンスとバースト能力は、CPU クレジットによって決まります。CPU クレジットは、フル CPU コアのパフォーマンスを 1 分間提供します。vCPU の数、使用率、および時間の他の組み合わせも、1 つの CPU クレジットに相当します。たとえば、1 […]

異なる業界からの AWS のお客様は、標準の SSH ファイル転送プロトコル (SFTP) を使って他の組織とデータを交換する必要があります。このようなデータの例には、財務記録、メディアファイル、あるいは健康記録や個人の財務データなどの機密情報が含まれます。SFTP は、SSH プロトコルで採用されているものと同じ公開キーや秘密キーの暗号化メカニズムを使用し、これらのファイルを転送するための安定したかつセキュアな転送メカニズムを提供します。AWS Transfer for SFTP (AWS SFTP) は、データが Amazon Simple Storage Service (Amazon S3) に保存されている場合、SFTP 経由の転送を可能にする完全マネージドサービスを提供し、こうしたニーズを満たします。 パブリックエンドポイントまたは Virtual Private Cloud (VPC) がホストするエンドポイントを使用することで、AWS SFTP サーバーをデプロイできます。パブリックエンドポイントを使用して、AWS SFTP サーバーに迅速かつ簡単にアクセスできます。または、VPC ホストのエンドポイントを使うことで、SFTP サーバーへのアクセスをより詳細に制御できます。 VPC でホストするエンドポイントのセキュリティを高めるため、VPC セキュリティグループと Elastic IP アドレスのサポートを最近追加しました。セキュリティグループを使用すれば、SFTP アクセスを特定のパブリック IPv4 アドレス範囲または IPv4 アドレス範囲に制限するルールを適用できます。許可された IP アドレスリストに含まれないエンドユーザーは、サーバーに接続できません。加えて、Elastic IP アドレスをサーバーエンドポイントに関連付けることができます。このため、ファイアウォールの背後にいるエンドユーザーを、静的 IP またはフェイルオーバー用の IP ペアで SFTP […]

これまで当社には、独立系ソフトウェアベンダー (ISV) であるお客様たちから、SaaS アプリケーションをデプロイする際に存在する、複数の検討事項についてのお話しが届いていました。これらの考慮事項の範囲は、総保有コスト (TCO) に関するものから、運用や俊敏性への影響などにまで及びます。また、セキュリティ、監査性、可用性の高さ、データ保護などに対処する必要もあり、それらはすべて、ブランド力やマーケットでの認知度に影響を与える要素である、というお話しも聞いています。オンプレミスでもクラウドの場合でも、セルフマネージドの共有ファイルストレージを必要とするアプリケーションでは、上記の基準を満足する技術的ソリューションを決定し維持することは簡単ではありません。 今回のブログでは、マネージド型ストレージへの移行、そして完全マネージド型でクラウドネイティブな Amazon Elastic File System (Amazon EFS) の活用に関し、当社が ISV であるお客様からうかがってきた事項のいくつかをご紹介していきます。 総所有コスト (TCO) ISV のお客様からは、セルフマネージド型ストレージのプロビジョニングとキャパシティ管理に関連し、TCO に影響を与える複数の要素についてうかがっています。これらの要素には、管理上のオーバーヘッド、利用されないキャパシティ、コロケーション (施設、異なる使用条件、別々の契約) 、ハードウェア、そして帯域の問題などが含まれます。Amazon EFS をご利用になるお客様では、セルフマネージド型ファイルストレージのソリューションと比較して最大 90% の節約が可能です*。 Amazon EFS は伸縮自在にスケーリングするため、お客様はファイルの追加や削除に合わせ、自動的に利用量を拡大や縮小することができます。プロビジョニングや管理用のキャパシティを確保する必要はありません。さらに、ストレージボリューム管理の複雑さから逃れられ、実際に必要な分だけを支払えば良い、という別の利点もあります。EFS ライフサイクル管理では、毎日アクセスしないファイルを、EFS Infrequent Access ストレージクラスに透過的に移動することで、コスト削減幅のさらなる調整が可能です。このストレージクラスのコストは 0.025 USD/GB (毎月) だけです (料金は米国東部 (バージニア北部) リージョン) 。 さらに言えば、EFS には、マルチアベイラビリティゾーンアーキテクチャにより提供される追加的なコスト削減手法もあります。これにより、お客様がアプリケーションをスケールアウトする際、コンピューティングに合わせて、よりコストの低い EC2 スポットインスタンスを選択することが可能です。 運用上のシンプルさ ISV のお客様は、予測が不可能な顧客数の増大に合わせスケーリングするために、ビジネスが俊敏さを備えることの重要性についても、お話しくださっています。この課題に関係する要素は、アプリケーション向けにストレージの信頼性を確保することから、新たなマーケットに移動することの煩雑さにまで及びます。また、タイミングを見計らって市場投入することや、コロケーション、ハードウェア、および帯域などの調達リスクについても考慮する必要があります。加えて、セルフマネージド型ストレージソリューションでは、貴重な資本と開発リソースが、インフラストラクチャのデプロイと維持により拘束されるというご意見もありました。 Amazon EFS では、完全マネージド型のストレージソリューションをご利用いただけます。つまり、キャパシティを保持するために、ハードウェアもしくはインフラストラクチャの管理を気にする必要がないということです。さらに、利用量の最適化などを気にする必要もありません。このサービスは、一切の関与を必要とせずに自動で拡大および縮小するので、支払いは実際に利用した分のみです。全体的に見て最も優れている点は、インフラストラクチャの管理から開発リソースを解放できる点であり、アプリケーションに付加価値を追加する作業に注力できるようになります。Faculty 社のデータエンジニアである Scott Stevenson 氏は次のように言います。「偉大なテクノロジーの証しとは、その存在を忘れることができるということです。Amazon […]

これは Memsource のゲスト投稿です。彼らの言葉によれば、「AI を搭載した翻訳テクノロジーで業界を先導することにより、より簡単に、より速く、そしてさらに費用対効果の高い方法でローカリゼーションを行います」とのことです。 Memsource と Amazon Translate は、パートナーシップを強化しています。Memsource の機械翻訳 (MT) 管理機能である Memsource Translate で Amazon Translate を使用できるようになりました。 多くの Memsource ユーザーから共通の問題をお寄せいただきました。選択する機械翻訳エンジンが多すぎるため、ソースコンテンツの翻訳に最適な結果を決定するプロセスが難しくて面倒だというご意見でした。さらに、エンジンが頻繁に変更され、常に新しい言語ペアが追加されます。Memsource の社内評価によると、70% 以上の翻訳プロジェクトで、顧客は最も効果的な機械翻訳エンジンを使用できていないことがわかりました。 Memsource Translate は、内容に最適なエンジンを自動的に選択する、新しい機械翻訳管理機能です。高品質の翻訳を簡単かつ迅速に提供します。また、Memsource の AI を搭載した機能の最新バージョンである機械翻訳品質推定 (MTQE) も含まれています。この機能は、事後編集が行われる前に、リアルタイムで機械翻訳出力の品質スコアを提供します。 サポートされているエンジンの 1 つとして Amazon Translate が追加されたことをお知らせいたします。 Memsource アカウントさえあれば、Amazon Translate で Memsource Translate を使用できます。初めてサインアップすると、無料 Memsource Translate といった文字が表示され、内容をテストできます。 選択機能 選択は、翻訳の言語ペアに基づいています。次の図は、そのプロセスを示しています。 内容をアップロードして言語ペアを選択すると、Memsource Translate は最高ランクのエンジンを自動で選択します。その後、機械翻訳の品質スコアを確認できます。その結果、翻訳者の生産性が向上し、コストが削減されます。 将来の展望 今後数か月のうちに、テキストのコンテンツタイプ (分野) […]

Amazon Elastic Inference を使用して、Amazon SageMaker と Amazon EC2 の両方で PyTorch モデルの推論を加速し、推論コストを削減できるようになりました。 PyTorch は、動的なコンピューティンググラフを使用する一般的なディープラーニングフレームワークです。これにより、命令的で慣用的な Python コードを使用してディープラーニングモデルを簡単に開発できます。推論は、トレーニングされたモデルを使用して予測を行うプロセスです。PyTorch などのフレームワークを使用するディープラーニングアプリケーションの場合、推論は計算コストの最大 90% を占めます。ディープラーニングモデルはさまざまな量の GPU、CPU、およびメモリリソースを必要とするため、推論に適切なインスタンスを選択することは困難です。通常、スタンドアロン GPU インスタンスでこれらのリソースの 1 つを最適化すると、他のリソースが十分に活用されなくなります。したがって、未使用のリソースに対して料金を支払うことになる可能性があります。 Elastic Inference は、Amazon SageMaker インスタンスタイプや EC2 インスタンスタイプ、または Amazon ECS タスクに適切な量の GPU による推論アクセラレーションをアタッチできるようにすることで、この問題を解決します。アプリケーションの全体的なコンピューティングとメモリのニーズに最適な AWS の CPU インスタンスを選択し、アプリケーションのレイテンシー要件を満たすために適切な量の GPU による推論アクセラレーションを個別にアタッチできます。これにより、リソースをより効率的に使用し、推論コストを削減できます。PyTorch が、Elastic Inference でサポートされるディープラーニングフレームワークとして TensorFlow と Apache MXNet に加わります。この記事の執筆時点でリリースされているバージョンは 1.3.1 です。 この記事では、Amazon EC2 インスタンスと Elastic […]