Container Insights でコンテナ単位のCPU・メモリ使用率を表示させる方法 | DevelopersIO
ちゃだいん（@chazuke4649）です。 Container Insightsの活用にあたり、ちょっとハマった箇所があったので共有します。 結論 Container Insights を有効化しただけでは、コンテナ単位のCPU・メモリ平均使用率が表示されない場合がある タスク定義内のコンテナ定義にて、コンテナごとにCPUとメモリを指定して起動すると、Container Insightsで表示されるようになる 前提 まず、そもそも Container Insights については以下ブログや資料がわかりやすいです。 [Black Belt] Amazon CloudWatch Container Insights で始めるコンテナモニタリング入門 AmazonECS用のAmazonCloudWatch ContainerInsightsの紹介| AWS Management＆Govern
ECSでEFSを使いこなすための一歩としてEC2ベースでのCPUとメモリ設定にトライしてみた | DevelopersIO
初めてECSでEC2ベースの操作を行う際、壁の一つになると思われるCPUとメモリの扱いについてまとめてみました。 はじめに 「FargateではEFSが使えないけど、EC2だとリソース管理が面倒。どうしよう」 と、Fargateの手軽さに魅力を感じた上で悩まれる方は少なからず居られるものだと思います。 ECSからマウント経由で外部ファイルにアクセスしたい場合は自ずとEC2が手段として上がってきます。Fargateにてイメージファイル内にgitやboto3等で外部から取り込む術を作り込む手もありますが、動作検証が茨の道であることは間違いありません。 EC2になくてFargateにある大きな特徴は、リソース管理がフルマネージドという点です。言い換えればリソース管理さえ覚えれば手立てはあるはずです。 今回は最初の壁になると個人的に思っている CPU と メモリ の扱いについて、調べながら只管繰り
Googleのソフトウェアエンジニアリングから学ぶコードレビュー
オライリー・ジャパンから「Googleのソフトウェアエンジニアリング」という翻訳の書籍が発売され、その中からコードレビューに関する箇所を読んで学んだことの紹介です。 サブタイトルの持続可能という表現が良い この本のサブタイトルは「持続可能なプログラミングを支える技術、文化、プロセス」です。 この持続可能（sustainable）の部分がとても響くものがあって、持続可能とするためにはどうしたら良いだろうか？ これを根源的な欲求として持ち、コードとコードレビューに向き合うのが本書では語られています。 実は、原著のサブタイトルは「Lessons Learned from Programming Over Time」で、 持続可能という直接的な表現はありません。 Over Time が刻を超越して、転じて持続していく様子につながると感じます。 持続可能の表現は、本文序文に sustainable
GitHub Actions / GitHub CLI を使った PR レビューをサポートする取り組み - Uzabase for Engineers
NewsPicks でサーバーサイドエンジニアを務めている池川です。 サービス運営をされている会社さんであれば、どの会社さんでも何らかの障害を起こし、その対策のための MTG を実施されていると思います。 が、サービスを長く運営していると、過去に発生してしまった事故と似た事故を発生させてしまうということが往々にしてあります。 NewsPicks でも、そのような事故が発生し、どうしたものかということが MTG での話題にのぼりました。 そこで、 NewsPicks ではそのような事故を風化させないための取り組みとして、事故が発生しそうな PR に対して、 GitHub Actions を用いて注意をうながすメンションを投げるワークフローを設定しました。 簡単な取り組みとなっているので、ご参考になれば幸いです。 背景 使用したツール 処理フロー GitHub Actions での実装 実際の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
