Category: Containers

AWS Lambda では、サーバーについて気にすることなくコードをアップロードして実行できます。多くのお客様に Lambda のこの仕組みをご活用いただいていますが、開発ワークフローのためにコンテナツールに投資した場合は、Lambda でのアプリケーションの構築に同じアプローチを使用することが難しくなります。 この問題に対応するため、Lambda 関数を最大 10 GB のコンテナイメージとしてパッケージ化し、デプロイできるようになりました。これにより、機械学習やデータ集約型のワークロードなど、大きな依存関係に頼る大規模なワークロードを簡単に構築してデプロイできます。ZIP アーカイブとしてパッケージ化された関数と同様に、コンテナイメージとしてデプロイされた関数は、同様の操作のシンプルさ、自動スケーリング、高可用性、多数のサービスとのネイティブ統合による恩恵を受けます。 当社では。サポートされているすべての Lambda ランタイム (Python、Node.js、Java、.NET、Go、Ruby) のベースイメージを提供しているため、コードと依存関係を簡単に追加することができます。Amazon Linux ベースのカスタムランタイム用のベースイメージも用意しており、これを拡張して Lambda ランタイム API を実装する独自のランタイムを含めることができます。 Alpine や Debian Linux をベースにしたイメージなど、独自のベースイメージを任意で Lambda にデプロイできます。Lambda を操作するには、これらのイメージに Lambda ランタイム API を実装する必要があります。独自のベースイメージの構築を容易にするため、当社ではサポートされているすべてのランタイムにランタイム API を実装する Lambda Runtime Interface Clients をリリースしています。これらの実装は、ネイティブのパッケージマネージャーを介して利用できるため、イメージ内で簡単に取得でき、オープンソースライセンスを使用してコミュニティと共有されます。 また、Lambda Runtime Interface Emulator をオープンソースとしてリリースします。これにより、コンテナイメージのローカルテストを実行して、Lambda にデプロイした際に実行されることを確認することができます。Lambda Runtime Interface Emulator は、AWS が提供するすべてのベースイメージに含まれており、任意のイメージでも使用できます。 コンテナイメージは、Lambda Extensions […]

この記事は、Introducing Amazon ECS Anywhere を翻訳したものです。 2014 年、AWS は EC2 インスタンス上で稼働する様々な規模のコンテナの管理を簡潔にするために Amazon Elastic Container Service (Amazon ECS) を発表しました。Amazon ECS の採用が増えるにつれて、お客様は「Undifferentiated Heavy Lifting」(差別化につながらない重労働) である、コンテナを実行するための EC2 インスタンスの管理を取り除くという新しい問題に対応していました 。そして 2018 年、AWS はコンテナを実行するためのインフラストラクチャの管理が不要なサーバーレスプラットフォームである AWS Fargate を発表しました。 この 2 年間、お客様は Amazon ECS を利用したコンテナのデプロイが、より多くの場所で行える柔軟性を求めていました。AWS リージョンの外部で、他の連携するサービスの近くでアプリケーションを実行するようなユースケースが増えていました。2019 年と 2020 年に、AWS は Amazon ECS のタスクを AWS リージョンの外部で実行可能にするオプションに関する一連の発表を行いました。AWS Outposts は、AWS が所有・管理するハードウェアを利用して、AWS のインフラストラクチャ、サービス、API、そしてツールをお客様のオンプレミス環境に拡張します。AWS Wavelength と AWS Local […]

AWS ソリューションアーキテクトの落水です。Amazon ECS や Amazon EKS をご利用中のお客様同士で情報交換をしていただくイベント「コンテナラウンドテーブル」の第二回が、2020 年 11 月 10 日にオンラインで開催されました。第一回の様子は、こちらの開催報告のブログをご確認ください。第二回では 5 社の企業様にご参加いただき、CI/CD パイプラインやコストの最適化など、いくつかのトピックを設定して情報交換およびディスカッションが行われました。 当日のタイムテーブル 14:00 – 14:35: 情報交換 AWS のコンテナサービスをどのように活用しているのか、各企業様からユースケースをご紹介いただきました。参加者の方からは『他社様の運用実績や課題を知ることができ、とても参考になった』などの声もいただいており、有意義な情報交換が行われました。 14:35 – 15:25: ラウンドテーブル 参加された各企業様には事前にアンケートを回答していただき、ご要望の多かったトピックについてラウンドテーブルを実施しました。ラウンドテーブルには、AWS からソリューションアーキテクトの加治・濱、プロダクトデベロッパーアドボケイトの Tori Hara も加わりディスカッションが行われました。ラウンドテーブルで行われたディスカッションについて、いくつかの内容をピックアップしてご紹介します。  デプロイにおいて課題に感じている点は？ CI/CD パイプラインを構築しているが、ロールバックなど一部のオペレーションが手動になっているため、できれば自動化したい ロールバックについて、アプリケーションの状態が追いやすかったり、管理がしやすい方法があれば知りたい 例えば Amazon ECS では、デプロイに AWS CodeDeploy を利用することで Canary デプロイなどのトラフィックコントロールが可能となるので、トラフィックの切り戻しを含めてパイプラインに組み込むとロールバックの制御がやりやすくなる アプリケーションの状態は、ビジネスに近いメトリクスで健全かどうかを判断するのが望ましい CI/CD パイプラインはどのように構築している？ Amazon ECS は CI/CD が同一パイプラインだが、Amazon EKS は CI […]

AWS ソリューションアーキテクトの落水です。先日、Amazon ECS や Amazon EKS をご利用中のお客様同士で情報交換をしていただくイベント「コンテナラウンドテーブル」が開催されました。「コンテナラウンドテーブル」とは、Amazon ECS 及び Amazon EKS の情報共有を目的として、参加されたお客様における具体的な課題とその解決方法の情報交流を行っていただくイベントです。当日は、8 社の企業様にご参加いただき、コンテナのユースケースや運用上の課題について情報交換やディスカッションが行われました。

本投稿は Nathan Peck による記事を翻訳したものです アプリケーションをアイデアから人々に触ってもらえる実装に落とし込むのは複数のステップを含むプロセスです。設計が固まりコードが書かれると、どうやってそのアプリケーションをデプロイし、ユーザーのもとに届けるかというのが次のチャレンジとなります。その実現方法の１つが Docker コンテナを利用することであり、AWS Copilot のようなコンテナを実行するためのインフラストラクチャを自動的に構築してくれるようなツールです。もしあなたがまだ AWS Copilot のことをよく知らない場合は、以前のブログ記事「AWS Copilot のご紹介」をお読みいただくとその全体概要を掴んでいただけるかもしれません。 Copilot を利用すると copilot svc deploy のような CLI コマンドを実行することでアプリケーションのビルドやデプロイを実行することができますが、例えば複数の開発者が複数のサービスからなる規模のアプリケーションについて長期的な視点で考えた時には理想的な使い方とは言えません。この記事では、Copilot の基礎的な使い方に基づいてアプリケーションリリースの自動化を進める方法を紹介していきます。そこで、まずはコード変更をリポジトリにプッシュする度にコンテナアプリケーションをビルド、プッシュ、デプロイするという基本的なリリースパイプラインを動かすところから始めます。その後、複数のステージやテストを備え、プロダクションへのリリース前にそのアプリケーションが動作することを確認できるようなベストプラクティスをパイプラインを実装していきます。『本番環境で発見されたバグを修正し、それをユーザーに向けてリリースする』という現実世界のシナリオのウォークスルーが本記事のフィナーレです。 本日のアプリケーション あなたは “String Services” というオンライン文字列操作 API 界のトッププロバイダになることを狙っているスタートアップで働いているとしましょう。ある日、あなたの会社は “reverse.” と呼ばれる文字列操作のサービスを提供していくことを決めます。このサービスはどんな文字列もそのインプットとして受け入れ、逆向きの(reversed)文字列をその結果として返します。あなたの仕事はこの新しいサービスをデプロイし、この API を熱望するお客さまに届けることです。まずは Node.js で書かれたコードを見ていきましょう。 var getRawBody = require(“raw-body”); var http = require(“http”); var server = http.createServer(function (req, res) { getRawBody(req) .then(function (buf) { […]

機械学習と深層学習のモデルがより高度になるにつれて、高スループットで予測を素早く提供するためのハードウェアアクセラレーションの必要性も急増しています。本日より、AWS のお客様は、クラウドにおける高パフォーマンス性と最も低い予測コストのために Amazon ECS で Amazon EC2 Inf1 インスタンスをご利用いただけるようになります。これらのインスタンスは、数週間前から Amazon Elastic Kubernetes Service での利用が可能になっています。 EC2 Inf1 インスタンスの手引き Inf1 インスタンスは、AWS re:Invent 2019 でリリースされました。これらは AWS が一から構築したカスタムチップの AWS Inferentia を使用しており、機械学習の推論ワークロードが加速します。 Inf1 インスタンスは複数のサイズで利用可能で、1、4、または 16 の AWS Inferentia チップがあり、最大 100 Gbps のネットワーク帯域幅と最大 19 Gbps の EBS 帯域幅があります。AWS Inferentia チップには 4 つの NeuronCore が含まれています。いずれも高性能のシストリックアレイ行列乗算エンジンを実装しているため、畳み込みや変換などの一般的な深層学習のオペレーションを大きく高速化します。NeuronCores には大容量のオンチップキャッシュも搭載されており、外部メモリからのアクセスを削減し、プロセスの I/O 時間を節約できます。複数の AWS Inferentia チップが Inf1 […]

 Amazon Elastic Kubernetes Service (Amazon EKS) が、AWS Fargate でアプリケーションを実行可能にKubernetes ポッドは EC2 インスタンスをプロビジョニングして管理することなく、実行できます。Fargate は すべてのポッドを VM 分離環境で実行するため、daemonsets の概念は現在 Fargate には存在しません。したがって、Fargate を使用しているときにアプリケーションログをキャプチャするには、アプリケーションがログを出力する方法と場所を再検討する必要があります。このチュートリアルでは、Fargate で実行されているポッドのアプリケーションログをキャプチャして出荷する方法を示します。 Kubernetes ログ記録アーキテクチャ 最新のアプリケーションを構築するためのゴールドスタンダードを示す Twelve-Factor App マニフェストによると、コンテナ化されたアプリケーションは、ログを stdout および stderr に出力する必要があります。これはまた、Kubernetes のベストプラクティスと見なされ、クラスターレベルのログ収集システムはこの前提で構築されています。 Kubernetes ログ記録アーキテクチャは、次の 3 つの異なるレベルを定義します。 基本レベルのログ記録: kubectl を使用してポッドログを取得する機能 (例:kubectl logs myapp – myapp はこのクラスターで実行されているポッドです) ノードレベルのログ記録: コンテナエンジンは、アプリケーションの stdout と stderr からログをキャプチャし、ログファイルに書き込みます。 クラスターレベルのログ記録: ノードレベルのログ記録に基づく。ログキャプチャエージェントは各ノードで実行されます。エージェントはローカルファイルシステムのログを収集し、Elasticsearch や […]

 はじめに 現在、同じ Kubernetes クラスターで実行されている複数のテナント間を完全に分離することは不可能です。その理由は、Kubernetes がクラスターごとに 1 つのコントロールプレーンを持ち、クラスターで実行されているすべてのテナントが同じコントロールプレーンを共有するように設計されているためです。1 つのクラスターで複数のテナントをホストすると、いくつかの利点がもたらされます。主な利点には、効率的なリソースの利用と共有、コストの削減、設定のオーバーヘッドの削減があります。 ただし、マルチテナントの Kubernetes セットアップでは、リソースの共有とセキュリティに関して特殊な課題が生じます。これについての理解を深めましょう。共有クラスターの目標の 1 つは、各テナントが利用可能なリソースを公平に共有し、その要件を満たすことです。この場合に緩和する必要があると考えられる副作用に、ノイズの多い隣接効果があります。これは、テナント間で適切なレベルのリソース分離を保証することにより対処します。2 番目の課題にして主な課題は、セキュリティです。悪意のあるテナントが他のテナントを危険にさらすことを避けるには、テナント間の分離が必須です。分離メカニズムによって実装されるセキュリティレベルに応じて、業界では共有テナンシーモデルをハードとソフトのマルチテナンシーに分割しています。 マルチテナンシー ハードマルチテナンシーは、テナント間の信頼がないことを意味し、1 つのテナントは他のテナントの何にもアクセスできません。このアプローチは、たとえば、互いに知られていない複数のテナントをホストするサービスプロバイダーに適しています。このセットアップの主な焦点は、テナント間でビジネスを完全に分離することです。オープンソースコミュニティでは、この課題を解決するための作業が進行中ですが、このアプローチはまだ本番ワークロード全体では広く使用されていません。 ハードマルチテナンシーの対極にあるのが、ソフトマルチテナンシーです。これは、同じ組織またはチームの一部である可能性のあるテナント間に信頼関係があることを表します。このアプローチの主な焦点は、セキュリティの分離ではなく、テナント間のリソースの公平な利用です。 オープンソースコミュニティには、ソフトマルチテナンシーを実装するための取り組みがいくつかあり、その 1 つが Kiosk です。Kiosk は、Kubernetes クラスターにソフトマルチテナンシーを実装するためのオープンソースフレームワークです。この記事では、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに実装するためのステップバイステップガイドを示します。 初期設定 セットアップを続行する前に、次の前提条件を満たしていることを確認してください。 AWS アカウントにログインします。 AWS マネジメントコンソールで Amazon EKS クラスターを作成します。 ローカルマシンから Amazon EKS クラスターに接続します。 ローカルマシンに kubectl をインストールします。これは、Kubernetes クラスターを制御するためのコマンドラインツールです。 ローカルマシンに helm バージョン 3 をインストールします。これは Kubernetes […]

 サービスアカウントへの IAM ロール (IRSA) の導入により、Kubernetes でのワークロード要件に固有な IAM ロールを作成できるようになりました。このため、ノードレベルではなくポッドレベルでの詳細に設定されたロールを作成でき、最低限の特権のセキュリティ プリンシパルも有効になります。このブログ投稿では、ポッドのクロスアカウントロールを引き受ける必要があるユースケースを見ていきます。 ユースケース デベロッパーアカウントと shared_content AWS アカウントがある、次のシナリオを考えてみましょう。Amazon Elastic Kubernetes Service (Amazon EKS) クラスターのポッドとしてデベロッパーアカウントで実行する開発ワークフローでは、shared_content アカウントの pics S3 バケットに保存されているいくつかの画像にアクセスする必要があります。 IRSA 以前の手順 IRSA 導入前に shared_content アカウントの pics バケットにアクセスするには、次の手順を実行します。 shared_content アカウントに S3_Pics ロールを作成し、shared_content アカウントとデベロッパーアカウントの間に信頼関係を作成します。 S3_Pics ロールにポリシーを添付して、ReadOnlyAccess が pics バケットへのアクセスのみを許可するようにします。 Amazon EC2 信頼関係ポリシーをデベロッパーアカウントの Amazon EKS (EKS) ワーカーノードロールに添付します。. EKS ワーカーノードのロールにポリシーを添付し、EKS ワーカーノードが sts:AssumeRole 操作を実行できるようにします。 […]

先日 (2020/6/24) 開催しました AWS Black Belt Online Seminar「Container Service Update」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200624 AWS Black Belt Online Seminar Container Services Update AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. 6月上旬に「今後数か月で、AWS Fargate は LATEST フラグをプラットフォームバージョン (PV) 1.4.0 に更新する予定です。」という通知がされていますが、「今後数か月」はどの程度の期間と考えればよいでしょうか？1.4.0 の移行のどちらを優先するかを決めたい考えております。 A. 現在アナウンスさせて頂いている時期は、2020-3Q、2020 年 7 月 – 9 月となっております。下記 Blog でもご案内しておりますが、正式な発表をお待ちください。 日本語訳：https://aws.amazon.com/jp/blogs/news/aws-fargate-platform-versions-primer/ 原文：https://aws.amazon.com/blogs/containers/aws-fargate-platform-versions-primer/ Q. Docker Engine を使っていたら、platform を 1.3 以上から二度とアップグレードできない、と考えてよろしいのでしょうか？ Containerd にはしたくない、というお客さまがいた場合、です。 A. […]