Amazon Web Services ブログ

Category: Containers

AWS Copilot によるコンテナアプリケーションの自動デプロイ

本投稿は Nathan Peck による記事を翻訳したものです アプリケーションをアイデアから人々に触ってもらえる実装に落とし込むのは複数のステップを含むプロセスです。設計が固まりコードが書かれると、どうやってそのアプリケーションをデプロイし、ユーザーのもとに届けるかというのが次のチャレンジとなります。その実現方法の1つが 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) { […]

Read More

Amazon ECS が EC2 Inf1 インスタンスのサポートを開始

機械学習と深層学習のモデルがより高度になるにつれて、高スループットで予測を素早く提供するためのハードウェアアクセラレーションの必要性も急増しています。本日より、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 […]

Read More

AWS Fargate で Amazon EKS を使用するときにアプリケーションログをキャプチャする方法

 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 や […]

Read More

Amazon Elastic Kubernetes Service で Kiosk にソフトマルチテナンシーをセットアップする

 はじめに 現在、同じ 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 […]

Read More

Kubernetes サービスアカウントのクロスアカウント IAM ロール

 サービスアカウントへの 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 操作を実行できるようにします。 […]

Read More

[AWS Black Belt Online Seminar] Container Service Update 資料及び QA 公開

先日 (2020/6/24) 開催しました AWS Black Belt Online Seminar「Container Service Update」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200624 AWS Black Belt Online Seminar Container Services Update from Amazon Web Services Japan 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 を […]

Read More

AWS Copilot のご紹介

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 チームのエンジニアや […]

Read More

Prometheus と Grafana を使用して AWS Fargate で Amazon EKS をモニタリングする

 AWS では、複雑さを軽減することで常に顧客体験の向上を目指しています。お客様は、ビジネス問題の解決に取り組むためにより多くの時間を費やし、インフラストラクチャの保守にかける時間を減らしたいと考えています。2 年前に、Kubernetes クラスターを簡単に操作できるように Amazon EKS をリリースしました。そして昨年の re:Invent 2019 で、Fargate で EKS のサポートを開始することを発表しました。この機能により、EC2 インスタンスを作成および管理せずに Kubernetes ポッドを実行できます。 お客様から、「Prometheus を使用して Fargate で実行されているポッドを監視できますか?」という質問がよく寄せられます。 はい、Prometheus を使用して Fargate で実行されているポッドを監視できます。Fargate でポッドがどのように実行され、関連する Prometheus メトリックがどこで発生するかを詳しく見ていきます。 Fargate で Kubernetes ポッドを実行する AWS Fargate は、Amazon Elastic Container Service (ECS) と Amazon Elastic Kubernetes Service (EKS) の両方で機能するコンテナ用のサーバーレスコンピューティングエンジンです。Fargate で Kubernetes ワークロードを実行する場合、サーバーをプロビジョニングして管理する必要はありません。Fargate を使用すれば、コンテナを実行するための適切な量のコンピューティングを取得できます。Fargate でコンテナを実行できる場合は、ワークロード用に EC2 インスタンスのサイズを設定する必要性を回避できます。Fargate を使用すると、アプリケーションで必要なリソースを指定してその分を支払うだけで済みます。アプリケーションポッドに必要な vCPU […]

Read More

ECS 外部デプロイコントローラーを使用したブルー/グリーンデプロイ

  はじめに 継続的インテグレーション (CI) と継続的デリバリー (CD) は、現代のソフトウェア開発における重要なプラクティスです。それによりソフトウェアの配信を合理化して、ビジネス価値を迅速に提供できます。迅速な配信に加えて、現在のビジネス環境では、アプリのダウンタイムもほぼゼロであることが求められます。ブルー/グリーンデプロイが提供するソリューションは、チームが迅速に提供できるようにするだけでなく、機能のリリースに不可欠と考えられていた「メンテナンスウィンドウ」を排除するのにも役立ちます。大まかに言うと、このアプローチでは、新しいアプリケーションスタック (グリーン) を本番バージョン (ブルー) と並行してデプロイする必要があります。最初に、このグリーンスタックは生産負荷から分離され、安定性を確保するためにさまざまなテストが行われます。安定したと見なされると、本番トラフィック全体がブルースタックからグリーンスタックに移ります。Canary リリースは、時間の経過とともにトラフィックがゆっくりとグリーンバージョンに移行する手法のバリエーションです。この手法については、今後の記事で取り上げます。 Amazon ECS の場合、エンジニアリングチームが AWS CodeDeploy をデプロイに使用すると、ブルー/グリーンデプロイで必要なカスタム作業が軽減されます。ただし、CD のニーズに合わせて他のツールを利用するチームにとっては、ブルー/グリーンデプロイは課題のまま残ります。このようなチームが使用するソリューションの 1 つでは、アプリのブルーとグリーンバージョン用の個別のサービスを、ロードバランサーの背後にある個別のターゲットグループにデプロイする必要があります。ブルーからグリーンに切り替えるには、リスナールールでターゲットグループをスワップする必要があります。この方法は実用的ではありますが、ブルーバージョンとグリーンバージョンに個別の ECS サービスを作成する必要があるため、理想的ではありませんでした。ECS タスクセット、外部コントローラ、および ALB 向けの強化されたリクエストルーティング が導入されたことで、このブログは、外部ツールの Jenkins をどのように用いて、ブルー/グリーンおよび Canary パターンを実装する CD パイプラインを構築するかをご紹介します。 まず、このソリューションの主要コンポーネントを定義しましょう。 ソリューションコンポーネント タスクセット タスクセットには、関連付けられたタスク定義のバリエーションを介して、ECS サービスがアプリケーションの複数のバージョンを実行できるようにする情報が含まれています。論理的には、これはタスクカウント、ネットワーク設定、LB 設定などのパラメータを含むデプロイの単位を表します。これにより、基本的に、重要な設定を変更し、本番バージョンに影響を与えることなく、タスクの新しいバージョンの動作に影響を与えることができます。status パラメータは、現在本番稼働中のタスクセットであるプライマリはどれで、「Active」ではないタスクセットはどれかを表します。AWS CodeDeploy の場合、タスクセットはデプロイと 1:1 で関連付けられ、externalId フィールドにデプロイ ID があります。いったん定義されると、タスクセットはスケールパラメータの変更のみを許可します。この更新制約は、実際には、タスクセットの意図を分離境界として中継します。他のパラメータのいずれかを変更すると、混乱が生じる可能性があるため、最初にプロビジョニングされたときに「Active」とマークされる新しいタスクセットを作成する必要があります。 外部コントローラー ECS が提供するさまざまなデプロイタイプのうち、外部デプロイにより、デプロイプロセスを完全に制御できます。このデプロイプロセスは、選択したサードパーティーのデプロイコントローラー (この記事の場合は Jenkins) によって実行されます。カスタムデプロイプロセスとサードパーティーのコントローラーの使用は、サービス定義の deploymentController パラメータに「EXTERNAL」の値を使用して指定されます。 […]

Read More

Rafay が SonicWall によるコンテナと Amazon EKS の採用を加速

 この投稿は、AWS のプリンシパルソリューションアーキテクトである Carmen Puccio 氏と、Rafay Systems の共同創設者兼 CEO である Haseeb Budhani 氏によって提供されました 背景 有名なテクノロジー企業である SonicWall は、大企業や中小企業 (SMB) を保護するための幅広いセキュリティ製品のスイートを提供しています。設立以来、SonicWall はセキュリティ製品をハードウェアアプライアンスまたはダウンロード可能なソフトウェアとして提供してきました。SonicWall のお客様がアプリケーションをクラウドに移行し始めると、SonicWall はバックエンドと管理サービスにクラウドコンピューティングを採用するという戦略的な決定を下しました。さらに、SonicWall の大企業およびサービスプロバイダーであるお客様は、プライベートクラウド環境内で SonicWall の製品を利用しています。 重要な要件 クラウドパラダイムを十分に活用し、高度にスケーラブルなクラウドベースの一連の製品を提供するために、SonicWall は 3 つの重要な要件を特定しました。 コアサービスは、アプリケーションを複数のクラウドリージョンに簡単に分散できるように、Docker コンテナとして、マイクロサービスパラダイムを使用して再実装されなければならないこと。 世界各地で事業活動を行うお客様のため、成熟したマネージド型の一連のアプリケーションサービスを世界中の多数の場所で提供するクラウドプロバイダーを選択すること。 パブリッククラウド、オンプレミス、およびお客様の環境でのクラスターのデプロイとアプリケーションの運用を自動化する (Kubernetes ベースの) コンテナ化されたアプリケーションオーケストレーションおよび運用ソリューション。 マイクロサービスの採用 SonicWall のサイバーセキュリティと管理サービスのポートフォリオを最新化するというタスクには、同社のエンジニアリングチームとクラウド運用チームが極めて適任でした。また、チームは最新化の一環として、自社の各製品をサポートする管理ソリューションが複数のクラウドリージョンと数万のお客様のためにスケーリングできることを確認しました。 クラウドプロバイダーの選択 SonicWall は成熟した企業として、次のような成熟したプロバイダーと提携することを意図していました。 信頼性が高い グローバルなコンピューティングフットプリントを提供している 次のようなさまざまなマネージド型のサービスを提供している: 安全なネットワーク リレーショナルデータベースとドキュメントデータベース ログ管理 安全なコンテナレジストリ サーバーレス機能 これらの前提条件を考慮して、SonicWall はアマゾン ウェブ サービス […]

Read More