Category: Containers

この記事は、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. […]

Amazon Elastic Container Service (Amazon ECS) をご利用中、あるいはご利用を検討されている皆さまへ 本記事でご紹介する AWS Copilot は Amazon ECS CLI の後継に当たるものです。日本はこの ECS CLI を多くのお客様にご利用いただいている地域の1つであることに加え、ECS でのコンテナ実行をもっと簡単に行えるようにしたい、シンプルなワークフローを実現したいというリクエストを多数いただいていることから、本記事を英語記事と同じタイミングで公開することにしました。 Amazon ECS でのコンテナ実行に新たな体験を提供する AWS Copilot の紹介記事です。お楽しみください！ −トリ (皆さまからの Copilot へのフィードバック、心よりお待ちしております) 本記事は Nathan Peck による “Introducing AWS Copilot” を翻訳+加筆修正したものです Amazon ECS 向けの最初の公式コマンドラインツールは2015年に公開されました。2019年12月には、新たな体験を備えたコマンドラインツールのプレビューリリースを皆さまに紹介しました。お客様がこれまで以上に簡単にアプリケーションを Amazon ECS にデプロイできるよう、ゼロベースでデザインしたものです。そして本日、私たちはこの新たなコマンドラインツールの最新情報と、その新たな名前 – AWS Copilot – を紹介します。 AWS Copilot は、低レイヤなインフラの手動管理から脱却し、自身のアプリケーションとそのライフサイクルにフォーカスしたい ECS ユーザのためにデザインされました。Copilot は、ECS チームのエンジニアや […]