Amazon Web Services ブログ

Category: AWS App Mesh

Amazon EKS 上の AWS App Mesh での SPIFFE/SPIRE による mTLS の使用

本記事は、Efe Selcuk、Apurup Chevuru、Michael Hausenblas による Using mTLS with SPIFFE/SPIRE in AWS App Mesh on Amazon EKS を翻訳したものです。 AWS では、セキュリティを最優先事項と考え、責任共有モデルの観点から、お客様の責任部分をケアするためのコントロールを提供しています。サービスメッシュの一般的な使用例の 1 つは、通信経路のセキュリティ対策を強化することが挙げられますが、これは AWS App Mesh でも重点的に取り組んでいます。また、mTLS を安全かつ正しく利用するという課題は、実務者の間でも議論の対象となっています。AWS は App Mesh roadmap からの mTLS (mutual TLS、相互 TLS) の要望に応え、この機能のサポートを開始しました。このブログ記事では、mTLS の背景を説明し、Amazon Elastic Kubernetes Service (EKS) クラスターを使用したエンドツーエンドの例を紹介します。 背景 mTLS にあまり詳しくない場合は、このセクションをご覧ください。そうでない場合は、ウォークスルーに進んでください。 SPIFFE (Secure Production Identity Framework for Everyone) プロジェクトは、CNCF (Cloud Native […]

Read More

リクルートマーケティングパートナーズにおけるAmazon EKSとAWS App Meshを使った基盤安定性向上とGitOpsへの挑戦

本番環境でコンテナを利用したワークロードを構築する場合、ほとんどのケースでコンテナオーケストレーションのテクノロジが導入されます。AWS では、Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS)といったコンテナオーケストレーションに関するサービスを提供しています。 コンテナオーケストレーターの選定においては、各オーケストレーターの持つ機能や思想を理解することが重要です。Amazon ECS は、他の AWS サービスとシームレスに組み合わせることが可能であり、Amazon ECS をビルディングブロックの一つとして多様なワークロードをサポートするシステムを素早く構築可能です。Amazon EKS は、Kubernetes の持つエコシステムの利用や、カスタムリソースをクラスターに追加することにより、EKS クラスター上にワークロードの要件に応じたシステムを柔軟に構築することができます。これらの観点に加えて、ワークロードの要件を考慮した上でコンテナオーケストレーターを選択します。 一方で、ビジネスや組織の成長に伴い、コンテナオーケストレーターとワークロードがマッチしない状況が発生する場合があります。例えば、Amazon EKS でサービスを提供しているチームにおいて、サービスの拡充に伴い管理対象となる EKS クラスターやクラスター上のアプリケーションが増加した結果、Kubernetes バージョンのアップデート作業がチームで抱えきれないような負担になるかもしれません。この状況を解消する手段として、まず思いつくのがコンテナオーケストレーターの再選定ですが、コンテナオーケストレーターの移行には少なからず必要となる作業が見込まれるため、安易に決断することはできません。 しかしながら、コンテナオーケストレーターの移行により得られるベネフィットを評価できる場合、移行によるメリットが作業コストを上回る可能性があります。この評価を行うためには、現在の課題を正確に分析し、移行先となるコンテナオーケストレーターでは解決のためにどのようなアプローチが採用できるのか把握しておく必要があります。 本投稿では、リクルートマーケティングパートナーズが行なった Amazon ECS から Amazon EKS への移行を通じて、コンテナオーケストレーターの移行におけるベネフィットをどのように評価したのかを紹介します。合わせて、リクルートマーケティングパートナーズが Amazon EKS で導入したサービスメッシュと継続的デリバリーについて、その実例を紹介します。 リクルートマーケティングパートナーズ スタディサプリ ENGLISH SRE グループの大島 雅人氏、木村 勇太氏、横山 智大氏によるゲスト投稿 以下の投稿はリクルートマーケティングパートナーズの3つのブログ記事を元に再構成したものです。 概要 スタディサプリ ENGLISH の基盤を […]

Read More

AWS App Mesh と Kong を使って Amazon EKS 上でマイクロサービスを実行する

この記事は、Running microservices in Amazon EKS with AWS App Mesh and Kong を翻訳したものです。 本投稿は、Kong ソリューションエンジニアの Claudio Acquaviva、Kong アライアンスの Morgan Davies と共同で作成されたものです。 サービスメッシュはサービス間通信のための一般的なアーキテクチャパターンとなっている透過的なインフラストラクチャレイヤーです。Amazon EKS と AWS App Mesh を組み合わせることでマイクロサービスのための強力なプラットフォームを形成し、ロードバランシング、サービスディスカバリ、可観測性、アクセスコントロール、トレース、ヘルスチェック、サーキットブレーカーなどサービス間通信で発生する技術的な要件に対応する事ができます。 モダンなエンタープライズソリューションでは、次のカテゴリの明確な管理制御が必要です。 API エンドポイントへの外部からのイングレストラフィックをカバリングする API 管理 運用管理とサービスの状態に焦点を当てたサービス管理機能 サービスメッシュは主に 2 つ目のカテゴリに対応していますが、イングレストラフィックも同様に重要であり、スロットリング、アプリケーションとユーザの認証、リクエストログとトレース、データのキャッシングなどクラスタ全体のポリシーをサポートするソリューションから恩恵を受けることができます。これらのポリシーに加えてイングレスは使用状況の把握、課金システムの追加、運用上の閾値を超えたアラートの生成などの機能により、API のマネタイズを可能にするレイヤーです。 これらの機能はクラスタ外の周辺ツールを利用することで実現することも可能ですが、Kong for Kubernetes Ingress Controller は HPA、自己修復、RBAC、cert-manager などの Kubernetes の機能を活用して、アプリケーションと並行して稼働しているサービスメッシュを保護するソリューションを提供します。 この記事では、Amazon EKS、AWS App Mesh、Kong for Kubernetes を利用してサービスメッシュを安全に実装する方法について説明します。ここで取り上げる課題の範囲は API […]

Read More

re:Invent 2020: AWS Containers Track

re:Inventは11月30日 (月) 〜12月18日 (金) の3週間を通して開催される無料かつ完全オンラインのカンファレンスです。 今週より、登録済みのお客様は多岐に渡るAWSサービスに関するライブ及びオンデマンドのセッションへアクセスすることができます。本記事ではコンテナサービスのトラック、例えば Amazon ECS、Amazon EKS、AWS Fargate、Amazon ECR、AWS App Meshに関連するセッションについてご紹介させていただきます。また、お客様のフィードバックに基づき、今年は過去人気の高かった“Getting Started”セッションやリーダシップトーク、お客様事例のセッションを復活させました。 去年のre:Invent 2019からの進化をお客様へご共有できること、心より嬉しく思います。是非ご登録いただき、アジェンダよりご覧になりたいセッションをカレンダーへ追加してください。 ローンチセッション An introduction to Amazon ECS Anywhere, Massimo Re Ferre, Principal Technologist Amazon ECS キャパシティプロバイダーは、コンテナ化されたワークロードをさまざまなタイプのコンピュートキャパシティで実行できるようにする柔軟なルール定義機能およびそのキャパシティのスケーリング管理機能を提供するものです。本セッションでは、“オンプレミス”キャパシティプロバイダーがどのようにして多種のキャパシティ上で起動するAmazon ECSタスクやサービスを統一されたAPIを使って、コントロールプレーンの追加的ソフトウェアが必要なく管理できるかを見ていきます。オンプレミス、或いは別のクライド上でコンテナをAmazon ECSからオーケストレーションする方法についてご案内します。 セッション詳細 12月9日 2020 | 7:30 AM – 8:00 AM JST 12月9日 2020 | 3:30 PM – 4:00 PM JST 12月9日 2020 | […]

Read More

[AWS Black Belt Online Seminar] AWS App Mesh Deep Dive 資料及び QA 公開

先日 (2020/10/22) 開催しました AWS Black Belt Online Seminar「AWS App Mesh Deep Dive」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201014 AWS Black Belt Online Seminar AWS App Mesh Deep Dive from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. APM として New Relic を採用しています。 Envoy のコントロールプレーンとして Istio を利用した場合New Relic 提供の newrelic-istio-adapter が利用できますが、Envoy のコントロールプレーンとして AWS App Mesh を利用した場合どのような方法があるのか教えていただけますか?Roadmap の話は QA 対象外ということですので、現時点での代替案、ワークアラウンドなどについて教えていただけますか? A. […]

Read More

[AWS Black Belt Online Seminar] AWS App Mesh 資料及び QA 公開

先日 (2020/07/31) 開催しました AWS Black Belt Online Seminar「AWS App Mesh」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200721 AWS Black Belt Online Seminar AWS App Mesh from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. サービスメッシュはマイクロサービスアーキテクチャを構築する当初から導入すべきでしょうか?それとも、ある程度の規模になってから導入するべきでしょうか? A. マイクロサービスアーキテクチャを採用したワークロードを新規構築する様な場合は、当初から導入することを検討いただければと思います。一方で、規模が小さい間からマイクロサービスアーキテクチャで構築するべきか?といった観点も必要になります。最初はモノリスで開発し、ある程度の規模になって運用の中でシステムのコンテキスト境界が見えてきた段階でマイクロサービスをサービスメッシュと合わせて検討する、といった例もございます。 Q. アプリケーション間の直接通信からサービスメッシュへ移行するためのコスト・タスク量について知りたいです。 A. サービスメッシュへ移行するためのマイグレーション手段はいくつか考えられますが、Envoy を導入したアプリケーションを別途作成し、既存のアプリケーションを縮退させる方法などが考えられます。上記の作業に関して、アプリケーションの規模や通信方式によって移行コストやタスク量が異なってきますので、まず、検証環境でマイグレーションを実施し、事前にコストやタスク量を見積もるよう推奨いたします。 Q. AppMesh と Istio の互換性について教えて下さい A. App Mesh と Istio は、サービスメッシュとしてのモデルや API に互換性はありません。 Q. AWS Lambda のネットワーク通信でも App […]

Read More