AWS CloudWatchについての記事まとめ

個人メモ用記事

概要

【AWS】CloudWatch
CloudWatch 標準メトリクス(監視項目) 一覧
Black Belt Online Seminar Amazon CloudWatch
AWS Black Belt Techシリーズ Amazon CloudWatch & Auto Scaling
AWS Black Belt Techシリーズ AWS CloudTrail & CloudWatch Logs
AWS Blackbelt 2015シリーズ Amazon CloudWatch & Amazon CloudWatch Logs

ELB

CloudWatchのELB監視項目
あらたにELBを作成する時の、CloudWatch設定メモ
ELBの挙動とCloudWatchメトリクスの読み方を徹底的に理解する
CloudWatchのあるはずのメトリックスが存在しない理由
ELBのHealthyHostCountは全AvailabilityZoneの合計値をモニタリングできない?

EC2

死活監視

AWS CloudWatchでEC2の死活監視

メトリクス監視

新しいCloudWatch AgentでEC2インスタンスのメモリ使用率を監視する
[AWS] CloudWatch でロードアベレージとかメモリ使用量とか監視
ECSクラスタのCPUとメモリをCloudWatchメトリックスで取得してみた
EC2のメモリ使用量とdisk使用量をcollectdでサクッとCloudWatchに登録
AWS CloudWatch で、Amazon Linux のパフォーマンスとログの監視をしてみる
はじめてのCloudWatch(AWS) 〜カスタムメトリクスを作って無料枠でいろいろ監視する〜
AWS CloudWatch シェルだけでPutMetricDataを実行する
AWS CloudWatchでEC2を監視する (プロセス死活監視、ディスク使用率、iノード使用率を監視してアラートメールを送信する)

ログ取得

CloudWatch Logsを使ってログを集める!
CloudWatch Logsのインストール・設定
EC2インスタンスのログをCloudWatchで見る
AWS EC2でメモリ利用率をCloud Watchで監視する
nginxのエラーログをcloudwatch logsに送信する

RDS

Amazon RDS のモニタリング
CloudWatchのRDS監視項目

S3

Amazon CloudWatch を使用したメトリクスのモニタリング
S3のアクセス状況を可視化してみる

Auto Scaling

[翻訳]チュートリアル:CloudWatchアラームによるコンテナインスタンスのスケーリング

アラート設定

CloudWatchでエラーログの内容を通知させたい
CloudWatchアラームでSlackへ通知を行う。
AWS SNS(Amazon Simple Notification Service)の通知設定をしてみる

続きを読む

AWS Cloud9でAngularアプリ開発(後編)

はじめに

前編ではCloud9の環境構築をおこなったので、今回は実際にAngularの環境構築~実行までを行おうと思います。

node, npmのバージョンを確認

Angular-CLIは現状、nodeが6.9.0以上、npmが3.0.0以上必要なので、まずはバージョンの確認をします。
Cloud9にはIDE上にコンソールがあるので、そこにコマンドを入力すれば確認できます。
image.png
Cloud9はデフォルトでnodeが6.12.3、npmが3.10.10がインストールされているので問題なさそうです。

ちなみに、Cloud9ではワークスペース毎にEC2インスタンスが違うので、ワークスペースを別に立てればインストールされたモジュールを共有しなくてもよくなります。
つまり、今まで一台のPCではNodeなどのバージョン管理が大変でしたが、Cloud9を利用すればバージョン毎にワークスペースを立てれば済むようになるわけです。

Angular-CLIのインストール

Angularの開発にはかかせないAngular-CLIをインストールします。
Cloud9のコンソールに公式に記載されている通りに入力します。

npm install -g @angular/cli

体感で1分ほどでインストールが完了しました。

Angularプロジェクトの作成

Angular-CLIを利用してプロジェクトを作成します。
sample-angular-appの部分には作成するアプリ名が入るので、適宜読み替えてください。

ng new sample-angular-app
cd sample-angular-app

image.png
今回は2分ほどで完了しました。

Angularアプリを実行

まずは公式の通り以下のコマンドで起動してみます。

ng serve

起動したら、上部にあるPreview -> Preview Runnig Applicationを選択して、起動した画面を見てみます。
image.png
すると、「Invalid Host header」と表示されて失敗します。
これは、ホスト名が指定されたものと違うことが原因のようなので、ホスト名を明示して起動してみます。
ng serveのオプションの–publicを利用することでホスト名を明示することができます。
指定するホスト名には、Preview用ブラウザに記載されているURLをそのまま利用します。

ng serve --public https://xxxxxxxx.vfs.cloud9.ap-southeast-1.amazonaws.com

image.png

今度は上手くアクセスすることができました。
理由はわかりませんが、初回アクセス時にはロードに時間がかかるので辛抱強く待ちましょう。

起動コマンドをpackage.jsonに記載する

毎回URLを記載するのは面倒なので、起動コマンドをpackage.jsonに記載して省略出来るようにします。
今回修正するscriptの部分は、プロジェクトを作成した直後では以下の内容です。

  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build --prod",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },

この、”ng serve”のコマンドに –public https://xxxxxxxx.vfs.cloud9.ap-southeast-1.amazonaws.comを追加します。
修正後は以下のようになります。

  "scripts": {
    "ng": "ng",
    "start": "ng serve --public https://xxxxxxxx.vfs.cloud9.ap-southeast-1.amazonaws.com",
    "build": "ng build --prod",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },

修正を保存したら、実際に利用できるかを試してみましょう。
package.jsonで修正するのはnpmのコマンドなので、以下のコマンドで起動します。

npm run start

image.png

無事起動することが確認できました。

おわりに

前編から、AWS Cloud9を利用してAngularアプリの開発環境構築を行いました。
Cloud9を利用することで簡単に開発を始められるので、今後プロト等作成する時には積極的に利用していきたいです。

続きを読む

AWS Cloud9でAngularアプリ開発(前編)

AWS Cloud9とは

ブラウザ上で動作するIDEで、40以上の言語に必要なツールがあらかじめインストールされているため起動すればすぐに開発を始められる。
AWSが運営してるだけあって、AWSの他のサービスとの連携も簡単(らしい)。
複数人で同時に編集できたりハイライトした部分が相手からも見えるなど、ペアプロやコードレビューに向いた機能もある。

バージョン

ちなみにインストールされているバージョンは執筆当時で
Java : 1.7
node : 6.12.3
npm : 3.10.10
Python : 2.7.12
でした。
もちろんアップデートする方法はあるみたいです。

料金

Cloud9は基本的にEC2上で動作するようになっていて、課金はこの時に利用するEC2の料金のみ。
t2.microで構成すれば無料枠内で利用できる。
もちろんリッチな構成で作れば早くなる。
詳しくは公式を見てください。

AWS Cloud9環境の準備

では実際にCloud9の環境を準備してみます。
まずはCloud9のトップにアクセス。
すると、普段東京リージョンで利用している人はこんな画面に遷移したと思います。

キャプチャ.PNG

実はCloud9は現在東京リージョンには来ていないんです。
なので、おとなしく別のリージョンに移動しましょう。
するとこんな画面に遷移するので、右側にあるオレンジ色のCreate environmentをクリックしてCloud9の準備を始めましょう。
キャプチャ.PNG

Environment name and description

最初に環境の名前を設定します。
今回はcloud9-angular-sampleという名前にしました。
Descriptionの部分は環境の説明を書く部分なので今回は省略。

キャプチャ.PNG

Environment setting

次にCloud9を構築するサーバの設定をしていきます。

キャプチャ.PNG

Environment type

一番上のEnvironment typeは環境のタイプの設定です。
キャプチャ.PNG
上が新規にEC2インスタンスを作成してそこにCloud9環境を作る設定、
下が既存のEC2インスタンスもしくは自分で構築したサーバに環境を作る設定になります。
下の設定の場合には色々条件があるみたいなので公式の解説を参照するようにしてください。
今回は新規にインスタンスを作成するので上を選択します。

Instance type

新規インスタンスを選択すると、作成するインスタンスの構成を設定する必要があります。
image.png
今回は無料枠内で利用したいのでt2.microを選択します。
もちろんリッチな構成にすればそれだけ快適になるので、ここは好みで大丈夫です。

Cost-saving setting

この設定をすることで、Cloud9を使用していない時、自動的にインスタンスを閉じてくれるようになります。
キャプチャ.PNG
今回は30分に設定しておきました。

他の設定についてはデフォルトのままNextStepを押して先へ進みます。
キャプチャ.PNG

準備完了

確認画面のCreate environmentを押すと、グルグルしてる画面に遷移します。
image.png

初回はインスタンスの起動等々ありますが、だいたい1分ほどで準備が完了します。
キャプチャ.PNG

おわりに

前編はCloud9の環境構築までを行いました。
後編ではCloud9上でAngularの環境構築~実行までをやってみます。

続きを読む

AWSのPaaS, SaaSを利用して開発を効率化する

はじめに

  • AWSにはサーバやネットワークを提供するIaaSだけでなく、様々なPaaSやSaaSが提供されている
  • これらを利用することで開発効率を上げることが出来る
  • 今後の指針とするためにも、まずはどんなものがあるのか、どんな使い方が出来るのかを列挙してみる

対象

  • AWSって名前を聞いたことはあるけど実際よくわかってない人
  • クラウドっていうのはネット上にサーバがあるだけだと思ってる人

そもそもIaaS, PaaS, SaaSとは

IaaS

  • Infrastructure as a Service
  • サーバやストレージ、ネットワークといったインフラを提供するサービス
  • レンタルサーバなどのホスティングサービスと違い、サーバのスペックやOS等をユーザが選択することが出来る
  • AWSのEC2やGCPのComputeEngineなどが該当

PaaS

  • Platform as a Service
  • OSやミドルウェアを含めたプラットフォームを提供するサービス
  • インフラを管理する必要がなくなり、アプリケーションの構築に集中できるという特徴がある
  • AWSのLambdaやElastic Beanstalk、GCPのAppEngineなどが該当

SaaS

  • Software as a Service
  • アプリケーションまで含めたソフトウェア全体を提供するサービス
  • 利用者はインターネット上で利用するだけでいい
  • AWSのS3やCloudWatch, GoogleAppsのGmailやGoogleDriveが該当

分類方法

  • TomcatやNginxなどのミドルウェアを用意する必要があるのはIaaS
  • ソースコードなどのアプリケーションだけ用意すればいいのはPaaS
  • 設定するだけですぐ使えるようになるのがSaaS
  • 割と使い方によって変わる
    • 例えばS3を直接クラウドストレージとして使えばSaaSといえる
    • が、アプリケーションのバックエンドとして使うとPaaSっぽい
    • なので、あまり分類に意味はない気がする

AWSの代表的なPaaS, SaaS

Lambda

  • サーバの設定などなく、コードをデプロイするだけで実行可能になる
  • ElasticBeanstalkは構築をしてくれるサービスだが、こっちはサーバを意識する必要は全くない
  • PaaSではなくFaaS(Function as a Service)とも呼ばれる

S3

  • 主に画像や動画などの静的ファイルを置いておくクラウドストレージ
  • 一般的にはアプリのバックエンドなどで利用するためPaaSと言えるが、別に単体でも使えるのでSaaSとも言える

Cognito

  • ユーザーの認証や管理、デバイス間の情報同期を行える
  • TwitterやGoogleなどのOpenID Connectプロバイダーとの連携も可能

API Gateway

  • 簡単にRESTfulAPIを作成、公開、管理できる
  • モニタリングやアクセス権の管理まで可能

CloudFront

  • ContentsDeliveryNetwork(CDN)サービス
  • キャッシュサーバーを利用したレイテンシの高速化やSSL通信、DDos対策などのセキュリティ設定が可能

DynamoDB

  • フルマネージドのKVS
  • テーブルを作成するだけですぐにスケーラブルなDBが利用できる

STS

  • AWSのリソースに対する一時的なアクセス権を管理できる
  • OAuth2.0でいう認可サーバの役割

ユースケース

バックエンドなしでSPAを作る

  • バックエンドのコーディングをすることなくユーザ認証を備えたSPAを作成出来る
  • 一部の仕様がAWSに縛られるので普通よりSPAのコード量は増えるかもしれない
  • が、自分でユーザ管理やアクセス管理を作るよりだいぶ楽かつ安全
    SPA.PNG

  • やっていることは

    1. Route53で独自ドメインを設定
    2. CloudFrontで高速化&SSL化
    3. S3で作成したSPAを配信
    4. Cognitoでユーザの認証を実施
    5. STSでユーザの認可を実施
    6. アクセス権にしたがってDynamoDBへアクセス

サーバを立てずにユーザ統合をする

  • 別々にユーザ管理を行っていたサービスのユーザ統合を行うような場合を想定
  • 普通にやると、各サービスとは別にユーザ管理用のサーバを立てる必要がある
  • AWSを利用すると、簡単にサーバレスな認証APIを作ることができる
    serverless.PNG
  • やっていることは
    • Cognitoを利用してユーザの管理、認証を行う

      • 外部からのユーザ取り込みにも対応している
    • Cognitoを利用するための処理をLambdaを利用して共通化する
    • API Gatewayを利用してRESTfulAPIとして公開
  • これによって、各サービスからRESTfulAPIを呼び出すだけで認証を行うことが出来るようになる
    • Cognitoの仕様上の制約は諸々あるので、サービス側の修正は多少必要

まとめ

  • とりあえずざっと書き出してみました
  • この辺を手がかりに何を勉強すればいいのか考えると良いと思います

続きを読む