Category: AWS Fargate

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

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

業界を取り巻く環境 世界的なパンデミックが日本にも影を落としている中、ストリーミングを使ったライブイベントの配信が驚異的な伸びを示しています。2020年の早い段階から、大規模なイベントや対面集会が次々に中止に追い込まれました。オリンピックが延期され、プロスポーツは無観客となりました。企業においても入社式や集合教育、株主総会といったものがソーシャルディスタンスの導入により大きな影響を受けています。この流れの中、ライブイベント配信を支える企業にはこれまで無縁だったビジネスを含め、様々な業界から無数の依頼が舞い込んでおり、その全てに対応するには非常に難しい環境にあります。

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

この記事は、How to build container images with Amazon EKS on Fargate を翻訳したものです。 本投稿は、Container Specialist Solutions Architect の Re Alvarez-Parmar により寄稿されました。 コンテナは、開発者がアプリケーションをパッケージ化、配布、そしてデプロイする方法を簡素化するのに役立ちます。開発者は、アプリケーションコード、ライブラリ、およびその他の依存関係を含むコンテナイメージにコードをパッケージ化します。このイメージを使用して、コンテナ化されたアプリケーションを互換性のある任意のオペレーティングシステムにデプロイすることができます。2013 年の Docker のリリース以来、コンテナの実行、イメージのビルドおよびリポジトリへのプッシュが容易に行えるようになりました。 ただし、Amazon ECS や Amazon EKS のような環境で Docker を使用してコンテナをビルドするには、Docker で Docker を実行する必要がありますが、これには重大な影響があります。おそらく、Docker を使用してコンテナ化された環境でコンテナイメージをビルドするための最も魅力的ではない前提条件は、特権モードでコンテナを実行する、という要件です。これは、セキュリティ意識の高い殆どの開発者が避けたい慣行です。Docker を使用してラップトップ上でイメージをビルドしても、セキュリティに深刻な影響はない場合があります。それでも、Kubernetes クラスターでコンテナに昇格された特権を与えることは避けるのが最善です。この厳しい要件により Fargate では特権コンテナが許可されていないため、Fargate で Docker と EKS を使用してコンテナイメージをビルドすることもできなくなります。 kaniko 特権モードを必要とせずにコンテナイメージをビルドする問題に対処するために、ここ数年で新しいツールが登場しました。kaniko は、Docker と同じように、Dockerfile からコンテナイメージをビルドするツールの 1 つです。ただし Docker とは異なり、Docker デーモンに依存せずに Dockerfile […]

この記事は、Running stateful workloads with Amazon EKS on AWS Fargate using Amazon EFS を翻訳したものです。 本投稿は、Container Specialist Solutions Architect の Re Alvarez-Parmar と Sr Technical Account Manager の Vikram Venkataraman により寄稿されました。 Amazon Elastic Kubernetes Service (EKS) では、EC2インスタンスまたは AWS Fargate で Kubernetes ポッドを実行することができます。コンテナ用のサーバーレスコンピューティングエンジンである AWS Fargate を使用すると、サーバーの作成と管理、データプレーンのスケーリング、EC2 インスタンスの適切なサイズ設定、ワーカーノードのアップグレードの処理を行うことなく、Kubernetes ワークロードを実行できます。今のところ Fargate は、ステートレスなコンテナ化されたワークロードを安全で費用対効果の高い方法で実行するのに理想的です。Fargate は VM で分離された環境で各ポッドを実行し、ノードに自動的にパッチを適用するため安全です。Fargate では、ポッド用に構成したコンピューティングリソースに対してのみ課金されるため、費用対効果が高まります。最近リリースされた Amazon Elastic File System […]

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

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、シニアエバンジェリストの亀田です。 2021年3月2日に日本で2番目となるリージョン、大阪リージョン が開設されました。その翌日3月3日にはフルマネージドなファイルシステムである Amazon EFSが利用可能となり、サービスラインナップの拡充が続けられています。 本日、バッチ処理をあらゆる規模で行うことの可能なフルマネージドサービスである、AWS Batch が大阪リージョンでご利用可能となりましたのでお知らせいたします。 バッチ処理とは、コンピュータでひとまとまりのデータを一括して処理する方式のことをさし、AWS Batchを用いることで、数十万件のバッチコンピューティングジョブを簡単かつ効率的に実行することができます。必要な特に大量のコンピュートリソースを確保し計算を行った後は、計算リソースが解放され、なおかつ、コンピューティングリソース (CPU やメモリ最適化インスタンスなど) の最適な数量とタイプを、送信されたバッチジョブの量と具体的なリソース要件に基づいて動的にプロビジョニングするため、Amazon EC2をベースとしたバッチ処理基盤より効率的な運用が可能となります。 AWS Batchの利用料金は無料であり利用した計算リソースに対してのみ発生します。2020年12月にはAWS Fargateに対応し、コンテナをベースとしたサーバレスなバッチ処理基盤を作れるようになりました。またスポットインスタンスの活用があらかじめ組み込まれており、よりコスト効率性の高い処理が可能となっています。 AWS Batchの詳細はこちらをご覧ください。 – シニアエバンジェリスト 亀田  

この記事は、Saving money a pod at a time with EKS, Fargate, and AWS Compute Savings Plans を翻訳したものです。 re:Invent 2019 では、Amazon Elastic Kubernetes Service (Amazon EKS) で、Kubernetes の Pod を AWS Fargate にデプロイできるようになったことが発表されました。その発表以降、多くのお客様が実際に Fargate 、つまりコンテナを実行するためのサーバーレスインフラストラクチャーに Kubernetes の Pod をデプロイしています。Fargate を利用することで、クラスターの管理やパッチの適用、セキュリティやアイソレーション、スケーリングといった様々な運用業務、「差別化にならない重労働( undifferentiated heavy lifting )」から解放されます。 Amazon EKS と Fargate の詳細については、re:Invent のブレイクアウトセッションでも掘り下げられています。 AWS Fargate は AWS Compute Savings Plans […]

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