ECS運用のノウハウ - Qiita
関連記事 マイクロサービスを支えるインフラアーキテクチャ (AWS Dev Day 2019登壇資料) ECSデプロイツールを公開しました ECSにおけるログの取り扱いを別ページに移動させました 設計 基本方針 基盤を設計する上で次のキーワードを意識した。 Immutable infrastructure 一度構築したサーバは設定の変更を行わない Infrastructure as Code インフラの構成をコードで管理 (Terraformを採用) Serverless architecture 無駄にサーバを増やさない アプリケーションレイヤに関して言えば、Twelve Factor Appが参考になる。コンテナ技術とも親和性が高い。 ECSとBeanstalk Multi-container Dockerの違い 以前に記事を書いたので、詳しくは下記参照。 Dockerコンテナデプロイ
Dockerコンテナデプロイサービスの比較 (Beanstalk Multi-container Docker/ECS) - Qiita
※1: CLIからのみ実行可能 Beanstalkの特徴 環境構築が楽。EC2+RDSという一般的なアプリケーションであればBeanstalkコンソールでほぼ完結 コンテナを用いないアプリケーションも構築可能 Multi-container Dockerを利用すると、裏でECSが動く (ECSを意識しなくてもアプリケーションが動く) Beanstalkはとにかく環境構築が簡単。ウィザードに従ってうっかり Create environment なんて押すもんならいきなりインスタンス起動してアプリケーションが動き出す。間違えて3回くらい押した。 Beanstalkは環境構築が簡単な反面、裏で何のサービスが連動しているのか分かりにくい側面もあります。障害が発生した時、問題の切り分け (コンテナが原因なのか、ECSか、それともBeanstalkの問題か) が困難となる印象です。 ちなみにBeans
DynamoDBにおけるテーブル設計 - Qiita
インフラ構成はこんな感じ。アプリケーションサーバが集計を行います。 Phase 4: Hot hash問題 データが3,000万超えた辺りからアクセスが集中するとCloudWatchからアラートが飛ぶように。。 The level of configured provisioned throughput for one or more global secondary indexes of the table was exceeded. Consider increasing your provisioning level for the under-provisioned global secondary indexes with the UpdateTable API 気付いたらいつの間にかデータサイズが10GB超。プロビジョニングされたスループットを超えた書き込みが発生していました。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
