Amazon Web Services ブログ

Category: Amazon Elastic Container Service

ECS のアプリケーションを正常にシャットダウンする方法

この記事は Graceful shutdowns with ECS を翻訳したものです。 — はじめに Amazon Elastic Container Service (Amazon ECS) を利用することで、お客様はさまざまな方法でコンテナ化されたアプリケーションを柔軟にスケールできます。リクエストの急増に対してタスクをスケールアウトすることも、コスト削減のためにタスクをスケールインすることもできます。ECS ではさまざまなデプロイの選択肢があり、ローリングデプロイ・ブルー/グリーンデプロイ・カナリアデプロイなどがサポートされています。さらに、ECS では柔軟なコンピューティングの選択肢が用意されています。Amazon EC2 のオンデマンド/スポットのキャパシティ上や、マネージドでサーバーレスなコンピューティング環境である AWS Fargate 上でも ECS のタスクを実行することができます。

Read More
AWS-CPG-DTC-Modernization

DTC e コマースサイトをモダナイズするための3つのステップ

筆者(Danny Yin)は15年以上にわたって、多くの革新的な消費者ブランドの e コマースプラットフォームの設計を支援してきました。特に消費者向け(Direct To Consumer; DTC)e コマースサイトにおける顧客体験の向上と運用効率向上を支援することが、AWS における筆者の役割です。 レガシーアーキテクチャに多額の投資を行っている消費財企業からも、クラウドベースの e コマースプラットフォームのメリットをどうすれば実現できるのかよく聞かれます。このブログでは、e コマースサイトをモダナイズするための3つの戦略について、その概要を紹介します。 DTC eコマースサイトの典型的なレガシーアーキテクチャはおわかりになりますね。オンプレミスのデータセンターに配置されたモノリシックアプリケーションで、DBA チームが巨大なウェブサイトを管理、チューニングしています。特にホリデーシーズンの購買ピーク時には、コストがかかる上に、拡張は難しく、管理にも時間がかかっていました。ここではこの点についてこれ以上深追いはせず、3 つのモダナイゼーションを見ていきましょう。 戦略1: DTC eコマースサイトをクラウドにリフト&シフトする パンデミックにより、eコマースからの売り上げは急増しました。オンプレミス環境または、プライベートクラウド環境にあるアプリケーションの場合、その ウェブサイトは大量のオンライン購買客の流入に対処しきれなかった可能性があります。おそらく ITチームはサーバー容量を追加する必要があったでしょう。それにより一時的には対応できたかもしれませんが、e コマース利用が続けば最終的に、容量制限を超える、予算を超えるといったことになりかねません。 この課題を解決するために、仮想サーバーにリフト&シフトします。これは、モダナイゼーションに向けた比較的簡単に取り組めるステップであり、すぐに以下のようなメリットを享受することができます: コスト削減 – AWS の従量課金制モデルをすぐに利用いただけます。使われていないサーバーに料金を支払う必要はありません。運用のベースラインとして Amazon EC2 リザーブドインスタンス(RI)を使用すれば、インスタンス価格はオンデマンドインスタンスと比較して大幅な割引価格(最大72%)で利用できます。次に、Amazon EC2 オンデマンドインスタンスを、またワークロードが適合するのであれば Amazon EC2 スポットインスタンスを使用します。スポットインスタンスを使うことでピークスループットは(オンデマンド価格と比較して)最大 90% 割引されます。 スケーラビリティ – AWS Auto Scaling により、ビジネス需要の変動に対応してサーバー容量をスケールインまたは、スケールアウトする柔軟性が得られます。 フォールトトレランス – Amazon EC2 Auto Scaling を使うことで、不健全なインスタンスを検出して新しいインスタンスで置き換えることができます。ITスタッフの運用負荷が軽減され、e コマースサイト全体の健全性と可用性が向上します。 メンテナンス容易性 – […]

Read More

AWS Service Catalog を使用しての、Amazon ECS 継続的デリバリー用の自動設計図の共有

この記事は、AWS Dev Tech のスペシャリスト SA である Mahmoud ElZayet が執筆しました  現代的なアプリケーション開発プロセスは、各組織がスピードや品質を継続的に向上することを可能にしています。このような革新的なカルチャーにおいては、小型の自律的なチームに、アプリケーションの全ライフサイクルがゆだねられます。ただ、こういった敏速かつ自律的なチームは、製品デリバリーを加速する一方で、コンプライアンスや品質保証、およびコードデプロイのためのインフラストラクチャに対するコストを生じさせます。 標準化したツールやアプリケーションリリース用コードを用いることで、チーム間でベストプラクティスを共有でき、冗長的なコードを削減し、オンボーディングを加速し、一貫性のあるガバナンスを作り上げながらリソースのオーバープロビジョニングを減らせます。   概要 今回の記事では、標準化され自動化されたデプロイ設計図を、AWS Service Catalog を使用して提供する方法をご紹介していきます。これは、製品チームによる Amazon ECS でのアプリケーションリリースワークフローの改善と迅速化に役立ちます。ここでの手順を実施していただくと、お客様の製品チームが ECS 上でコンテナ化されたアプリケーションをリリースするために使用できる、サンプル設計図が作成できます。この設計図のコンセプトは、サーバーレスや Amazon EC2 をベースとするデプロイなど、他のテクノロジーにも適用が可能です。 本稿で提供するサンプルテンプレートやスクリプトはデモ用に用意したものなので、実稼働環境でそのまま使用するには適しません。これらのリソースになじんだ後で、手元にあるツールや、チームのスキル、そして適用すべき規格や規制をすべて考慮しながら、実稼働環境向けにカスタマイズしたバージョンを作成してください。   前提条件 ここでのソリューションには、次に挙げる各リソースが必要です。 AWS アカウント での管理者アクセス権限 AWS CLI   サンプルシナリオ Example Corp という企業では、アプリケーションやサービスを AWS 上で開発するために、いくつかの製品チームを抱えています。同社内の各チームは、ECS 上の AWS Fargate で管理するコンテナ化したアプリケーションのデプロイに関心を示しています。ここでは、Example Corp. における主幹ツール管理チームとして、各チームが Fargate で迅速にアプリケーションをリリースできることを目指します。さらに、すべてのベストプラクティスやガバナンス要件を、各チームが準拠することも保証していきます。 事情を単純にするために、製品チームはすでに構成済みであり、サービスのデプロイ用に AWS のアカウントを共有しながら、同じドメイン、アプリケーション、もしくはプロジェクトで作業をしていると想定します。この 1 つのアカウントを通じ、チーム全体が同じ ECS […]

Read More

Amazon ECS 上の Linux コンテナでの Windows 認証の使用

この記事は、Using Windows Authentication with Linux Containers on Amazon ECS を翻訳したものです。 本投稿は、Sr Solutions Architect の Matt Cline により寄稿されました。 統合 Windows 認証 (または統合認証) は、クライアントおよびアプリケーションが SQL Server データベースに接続するための推奨メカニズムですが、コンテナ化されたワークロードを実行する場合、統合 Windows 認証の使用は複雑な場合があります。一般的に統合 Windows 認証クライアントは SQL Server データベースと同じドメインに参加しますが、個々のコンテナは恒久的な実行ではないためにドメインに参加することは適切ではありません。 この記事は、Amazon Elastic Container Service (Amazon ECS) で実行されている Linux コンテナを設定して、コンテナをドメインに参加させることなく、統合 Windows 認証を使用して SQL Server データベースに接続する方法を示します。この例では AWS Fargate を使用してコンテナを実行しますが、このソリューションを少し変更して別のコンテナランタイムまたはコントロールプレーンにデプロイすることもできます。 概要 この例は Microsoft Active Directory 用のAWS […]

Read More

New – Amazon ECS Exec による AWS Fargate, Amazon EC2 上のコンテナへのアクセス

この記事は、 NEW – Using Amazon ECS Exec to access your containers on AWS Fargate and Amazon EC2 を翻訳したものです。 本日、開発者、運用者を含むすべての Amazon ECS ユーザに向けて、 Amazon EC2 もしくは AWS Fargate にデプロイされたタスク内のコンテナに “Exec” する機能を発表しました。この新しい機能は、 ECS Exec と名付けられ、コンテナに対して対話型のシェル、あるいは一つのコマンドを実行できるようになります。これは AWS コンテナロードマップ上で最も要望の多かった機能の一つであり、一般公開できることを大変嬉しく思います。 ユーザが個々のコンテナに SSH 接続すべきでなく、監視やデバッグ、ログ分析のために適切な可観測性の仕組みを導入することは、コンテナ利用においてよく知られるセキュリティのベストプラクティスです。この発表は、ベストプラクティスを変更することなく、アプリケーションのセキュリティを改善するのに役立ちます。アプリケーション開発サイクルの初期段階においては、迅速なフィードバックループを回す必要がある場面がしばしばあります。例えば、あなたがローカル環境で開発とテストを行っていて、 docker exec を利用している場合、この新しい ECS の機能はきっと役に立つでしょう。またこの機能は、本番環境で重要度の高い問題をデバッグするために、コンテナへの “緊急用アクセス” が必要になる場合にも役立ちます。ここで、コンテナに対して “Exec” する時に利用できるツールと機能は、コンテナ内にインストールされているもののみであることに注意が必要です。つまり、例えば netstat や heapdump コマンドがコンテナのベースイメージにインストールされていない場合、それらを使用することはできません。 この機能をアナウンスするまでは、 ECS ユーザが EC2 […]

Read More

Docker Hub による AWS Container Services の認証

本投稿は Nathan Arnold による記事 Authenticating with Docker Hub for AWS Container Services を翻訳したものです。 Docker Hub は最近利用規約を更新し、コンテナイメージ Pull の rate limits を導入しました。これらの制限は Pro や Team プランのアカウントには適用されませんが、匿名ユーザーは IP アドレスごとに6時間あたり 100 Pull まで、認証済みの無料アカウントは6時間あたり200 Pull までと制限されています。この記事では、新たに設けられた制限による運用の混乱を回避し、プライベートコンテナイメージへのアクセスを制御するために、Amazon ECS と Amazon EKS の両方を使用してプライベートリポジトリからイメージを Pull するために Docker Hub で認証する方法を学びます。まだ Docker Hub を使用していない場合は、AWSクラウド環境とネイティブに統合されたフルマネージドの代替手段としてAmazon Elastic Container Registry (Amazon ECR) を検討してみてはいかがでしょうか。 Amazon ECS による Docker […]

Read More

Amazon ECS Fargate/EC2 起動タイプでの理論的なコスト最適化手法

この記事は、 Theoretical cost optimization by Amazon ECS launch type: Fargate vs EC2 を翻訳したものです。 本ブログは Julia Beck, Thomas Le Moullec, Kevin Polossat, and Sam Sanders によって投稿されました。 お客様から、 Amazon Elastic Container Service (Amazon ECS) のベストプラクティスについてご質問をいただくことがよくあります。特に、 Well-Architected Framework の コスト最適化 の柱に注目されるケースがあります。こちらに関する大きな要因の 1 つには、お客様が EC2 もしくは Fargate 起動タイプという選択肢をとることができるという点が考えられます。2019年には Fargate 起動タイプについて 最大50%の値下げ が発表され、また現在は Fargate Spot や Savings Plan も発表されており、大きく節約することが可能です。これらの考慮事項を踏まえて、 2 […]

Read More

AWS Fargate for Amazon ECS のアップデート

先日、AWS Fargate for Amazon ECS 経由でデプロイされたタスクの設定とメトリクスの収集体験を向上させる機能を発表しました。お客様からのフィードバックに基づき、以下の機能を追加しました。 環境ファイルのサポート シークレットバージョンと JSON キーを使用した、AWS Secrets Manager とのより深い統合 より詳細なネットワークメトリクスと、タスクメタデータエンドポイントを介して利用可能な追加データ この記事を通して、これらのアップデートについて深く掘り下げ、Amazon ECS for AWS Fargate にコンテナをデプロイすると、どこに価値をもたらすことができるかを説明します。まず、簡単なデモアプリケーションのデプロイから始めて、これらの各機能を説明します。

Read More

Amplify CLIを使い、労力ゼロでGraphQL/REST APIやウェブホスティング用にコンテナをデプロイする

この記事は、Zero-effort Container deployment for GraphQL and REST APIs and Web Hosting with Amplify CLIを翻訳したものです。 AWS Amplifyを使うことで、最速かつ簡単に、AWSでクラウド対応のモバイルアプリケーションやウェブアプリケーションを構築することができます。Amplifyは、フロントエンドのウェブ開発者やモバイル開発者が AWSの豊富なサービス群を活用して、革新的で多機能なアプリケーションを構築できるよう、ツール類や各種サービスを一通り備えています。 本日リリースしたAmplify CLIをお使いになることで、フロントエンドのウェブ開発やモバイル開発に携わるお客様は、コンテナを使ってAPI(GraphQL/REST)をデプロイしたり、ウェブアプリケーションをホスティングできるようになります。お客様ご自身のDockerfileまたは Docker Composeを持ち込むことで、Amplify CLIは、AWS Fargateを使用してコンテナを自動的にビルド、パッケージ、デプロイします。 メリット: 移植性の高いバックエンドの構築 – Amplify CLIは、シンプルなコンテナテンプレートを用意しているためすぐに始められます。または、お客様のチームがAPIやホスティング用のコンテナを既に使用している場合は、そのコンテナを利用することができます。 コンテナのデプロイパイプラインがすぐに使えるインフラ構成 – Amplify CLIは、VPC、サブネット、NACL、IAMポリシー、およびその他のセキュリティなどのインフラを管理するため、AWSに関する事前知識やインフラの実務経験は全く必要ありません。コンテナ間のネットワーキングは自動的に処理され、ホスティングされたサイトのSSL生成も自動的に処理されます。 ビルド&デプロイパイプラインを労力をかけることなく作成 – Amplify CLIはCodePipelineを作成し、イメージをビルド、デプロイします。パイプラインには、ビルドアーティファクトやイメージに対するライフサイクルポリシーなど、コスト最適化のベストプラクティスが備わっています。ビルドしてAWSにデプロイするためにDockerをお使いのシステムにインストールする必要すらありません。 構築するもの : 初めに、乱数を返すExpressJSサーバーを構築 次に、Python/Flask乱数生成サーバーでFizzBuzzアルゴリズムを実行する、ExpressJSを構築。 前提条件: 最新のAmplify CLIをインストール ターミナルを開き、 npm install -g @aws-amplify/cli を実行し、最新のAmplify CLIに更新。 Amplify CLIの設定 Amplify CLIをまだ設定していない場合は、ドキュメントページのこちらのガイド に従ってください。 […]

Read More

Amazon ECS deployment circuit breaker のご紹介

※日本語字幕の表示には、設定 → 字幕 → 自動翻訳 → 日本語をご選択ください EC2 および Fargate コンピュートタイプ用の Amazon ECS deployment circuit breaker をパブリックプレビューで発表しました。この機能により、Amazon ECS をご利用のお客様は、手動での作業を行うことなく、不健全なサービスデプロイを自動的にロールバックできるようになります。これにより、お客様は失敗したデプロイを迅速に発見できるようになり、失敗したタスクのためにリソースが消費されたり、デプロイが無期限に遅延したりすることを心配する必要がなくなります。 以前は、Amazon ECS でデプロイメントタイプにローリングアップデートを使用しているときに、サービスが健全な状態にならない場合、スケジューラは サービススロットリングロジック により永続的にデプロイを再試行していました。このデプロイの失敗を迅速に検知するには、追加でモニタリングの仕組みが必要であり、これは AWS CloudFormation を使用して Amazon ECS サービスをデプロイしているお客様にとっても厄介事の1つでした。 デプロイが失敗する理由はいくつかあり、例えば、コードやサービス構成に破壊的変更を加えた場合、希望のタスク数を立ち上げるために必要なリソースが不足している場合、コンテナやロードバランサのヘルスチェックに失敗した場合などです。ここで紹介したデプロイ失敗のシナリオは一部にしか過ぎず、deployment circuit breaker がどのような場面で役立つかを理解していただくための具体例として取り上げています。このブログの後半では、コンテナのヘルスチェックが失敗した場合のシナリオを例に deployment circuit breaker のデモを行います。   何をデプロイするか? デプロイするデモアプリケーションは Python Flask Web サーバを実行しており、ECS サービスを介してデプロイされたタスク定義の現在のバージョンを表示します。このサービスの作成、デプロイ、更新には AWS CLI を使用します。まずはコード、Dockerfile、タスク定義を見て、これからデプロイされる内容の理解を深めることから始めてみましょう。 この Flask アプリケーションは、タスクメタデータエンドポイントからタスクのバージョンを取得しており、ウェブサイトにアクセスすることで、ECS サービスが実行しているタスク定義のバージョンが表示されます。このアプリケーションは circuit breaker […]

Read More