Amazon ECSを用いたDocker本番運用の実現 - Qiita
はじめに 現在お手伝いしているアカウンティング・サース・ジャパンにて、ECSを使ったDockerの本番運用を始めたので、その一連の流れについてまとめました。 税理士向け会計システムを扱うアカウンティング・サース・ジャパンでは最近Scalaでの新規プロジェクトが立ち上がってきており、既存のプロジェクトはJavaであったり、Erlangであったりと様々な言語が用いられていますが、インフラ人員が少ないということもあり、なるべくシンプルなインフラ構成を実現する必要がありました。 そういった中、各アプリケーションをDocker化することでインフラとしては共通基盤としてのDockerクラスタのみの管理になり、運用コストが下がるのではないかという仮説からDocker化を進めることになりました。クラスタを実現するに辺りKubenatesなどの選択肢もありましたが、今回はECSを選択し、下記のようにAWSの
microインスタンスのCPU使用率はCloudWatchを信じろ - 日報 #113 - 俺の報告
解せぬ解せぬと思っていたことがようやく分りました。 嬉しい半面、異常に時間をロスしたことに地団ステップを踏まざるを得ません。 結論から先に書きます。 しかも箇条書きで。 t1.microのtopコマンドやvmstatでのCPU使用率は信じるな t1.microのCloudWatchのCPU使用率を信じろ かと言ってt1.microのvmstatコマンドとかから実際のCPU使用率を計算することはかなり難しい。（実質無理？） 安定してCPU監視のもと動作させたいなら、smallインスタンスから使え ということです。 サービスレベルでmicroを使う時は注意が必要というのは、 一見当たり前のようですが、 今回はその中でも重箱の隅をつつくような理由で説明させていただきます。 もちろん、下記の情報を知った上で上手にmicroを使えるのがハイパーいいことだとは思います。 さて、では簡単に説明を。 こと
Tomcatの使用メモリ量をCloudWatchで表示する | DevelopersIO
渡辺です。 現在のEC2のデフォルト機能では、EC2インスタンスのメモリ使用量をCloudWatchで確認することはできません。 ですが、AWS CLIと簡単なスクリプトを使えば、Custom MetricsとしてCloudWatchに表示することができます。 ただし、一般的なLinuxのメモリ使用量であればシェルスクリプトで簡単に取得できるのですが、TomcatなどのJavaのアプリケーションサーバではもう一手間必要です。 Javaでのメモリ管理の仕組み Java(JVM)はヒープ領域というメモリを仮想マシンの内部に確保し、ヒープ領域の中でインスタンスなどを割り当てる仕組みになっています。 したがって、OSから見たJavaのメモリ消費量を見ても、それはJVMが確保しているヒープ領域の使用メモリ量です。 内部的にどの程度メモリを消費しているかは解りません。 JVMのヒープ領域がどの程度メモ
ELBの挙動とCloudWatchメトリクスの読み方を徹底的に理解する | DevelopersIO
よく訓練されたアップル信者、都元です。ELBはAWSにおけるWebシステムを構築する場合、ほぼ確実に利用するコンポーネントとして不動の地位を確立しつつあります。 利用方法としては、ELBを作成して配下にWebサーバを配置するだけというお手軽さがあり、非常に利用しやすいのも大きなメリットです。しかし、ELBの詳細な挙動について、しっかり理解できているでしょうか。本エントリではいつも利用しているELBについて、ちょっと深く突っ込んでみました。 ELBのロードバランシング戦略 ELBの配下には複数のAZにまたがるようにインスタンスを配置するのが一般的です。（cf. AWSにおける可用性の考え方） ELBを作成すると、DNS名が付与されますが、クライアントがELBにアクセスする際、まずこのホスト名をIPアドレスに変換するDNSの正引きリクエスト（下図中の緑色の矢印）を行います。digコマンドを使っ
CloudWatchのELB監視項目 - Qiita
指定されたAvailabilityZoneでのロードバランサーに登録されたhelthyなEC2インスタンスの数。 unhealthyな閾値を超えてヘルスチェックに失敗していないホストはhealthyだとみなされる。 このmetricを評価する場合、dimensionはLoadBalancerNameとAvailabilityZoneで規定されるはずである。 このmetricは指定されたAvailability Zoneでのhealthyなインスタンスの数を表している。 200でない応答(HTTPやHTTPSでのヘルスチェックの場合)が返ったり、ヘルスチェックを行っている場合にタイムアウトするような接続の問題でインスタンスはunhealthyになることがある。 全てのhealthyなホスト数の合計を得るために、このmetricは各登録されたAvailabilityZoneを取得し、全てのme
【そんなときどうする？】CloudWatchのデータを2週間以上残したい！ - サーバーワークスエンジニアブログ
こんにちは。CS課の坂本です。 タイトルに【そんなときどうする？】をつけて、勝手にシリーズっぽくしてみました。実際に運用している案件でやっていることを中心に書いていきたいと思います！ ※「そんなときどうする？」となったときに、解決方法はいろいろあると思います。内容はあくまで解決方法の1つと思っていただければ、幸いです。 今回はズバリ、「CloudWatchのデータを2週間以上残したい！」です。 CloudWatchは、リアルタイムでAWSリソースのモニタリングが必要なときに、マネジメントコンソールでグラフを目視確認したり、Slackにアラートを飛ばしたりと、とても便利なモニタリングツールですが、2週間しかデータを保持できないので、単体で長期的な分析をすることはできません。 しかし、できればこのCloudWatchのデータをどこかに取っておいて、長期的な分析にも利用したいと思いませんか？ 正
CloudWatch 標準メトリクス(監視項目) 一覧 - Qiita
標準メトリクス一覧がネットで調べてもなかなかでてこなかったので、備忘録として残しておきます。 参考：http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-cloudwatch.html CPUUtilization 割り当てられた EC2 コンピュートユニットのうち、現在インスタンス上で使用されているものの比率。このメトリックスは、選択されたインスタンス上でアプリケーションを実行するのに必要な処理能力を表します。 単位: Percent DiskReadOps このインスタンスで利用できるすべてのエフェメラルディスクでの、完了した読み取り操作の数（インスタンスで Amazon EBS を使用している場合は、「Amazon EBS のメトリックス」を参照してください）。 このメトリックスは、一定の時間当たりの、アプリケー
Amazon Auroraの運用時に監視できる項目について | DevelopersIO
Amazon Auroraの運用について プレビュー版のAmazon Aurora使えるようになったので色々試しています。新しいDBエンジンということで、運用をどうするか気になっている方も多いのではないでしょうか。Amazon Auroraは、RDSの他のデータベースエンジンと同じように、CloudWatchで運用状況をモニタリングすることができます。これにより、正常稼働しているか、期待するパフォーマンスが出ているか確認することができますので、アラームを設定して運用に役立てることができます。 AuroraのDBクラスタ概念図 Aurora Metricsの種類 Auroraは、大きく分けて2種類の情報があります。Aurora System Monitoringと、Aurora SQL Monitoringです。前者は、ネットワーク/ディスク/CPUなどのシステムに関するモニタリングで、後者
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
