AWS Batchを使ってバッチ処理を実装してみた。

今回やりたかったこと

  • 社内で適用しているセキュリティのSaaSサービスのアップデートの自動化をしたい
  • 処理内容は、基本的にapiをコールしてこねこねしていくだけ

Lambdaでいいのでは?

  • SaaSが提供しているapiサーバーが、アクセス集中時だと5分経ってもレスポンスを返してくれない

そこでAWS BATCH

AWS BATCHとは

  • Job queueを受けた段階で、予め指定しておいたスペック(スペックが足りなかったら自動で最適なものを立ててくれるらしい?)のEC2を立ち上げてECRからコンテナイメージを持ってきてタスク実行してくれる
  • スケジュールを設定して実行してくれる!とかは無さそう。

アーキテクチャ

スクリーンショット 2017-03-19 22.05.34.png

Dockerfileはこんな感じ

FROM centos:latest
RUN curl -kl https://bootstrap.pypa.io/get-pip.py | python
RUN pip install awscli
RUN yum install -y git
ADD init.sh /opt/
CMD ["sh","/opt/init.sh","test"]

事前に処理実行に必要なコードだったりシェルスクリプトなんかは、ECRに含めておく。
シェルには、コードコミットから実行ソースをcloneするのに必要なssh key(事前にKMSとかで暗号化しておいたもの)、復号化処理、処理実行とかを書いておく。

あとは、Job queueを送ってあげれば、自動でEC2を立ち上げ、コンテナをマウントして最新のソースコードをcloneしてきて、処理を実行してくれます。
自動で立ち上がったEC2はタスク処理終了後(CMDのとこのやつ)、1時間単位の課金が切れるタイミング?で自動で削除されます。(立ち上がりっぱなしとかの心配なし!)

job queueに送信
aws --profile <profile> --region <region> batch submit-job --job-name <好きな名前> --job-queue <job queueの名前> --job-definition <定義したjob>

結果については、 Jobsの画面で確認することができます。
スクリーンショット 2017-03-19 22.17.59.png

まとめ

先日参加した「JAWS-UG KOBE」のコンテナまつりでHiganWorks sawanobolyさんがElasticDockerRunって呼んでるって言ってました。
DockerImageを基にいい感じに実行してくれるが、逆にBatch?なのかって印象でした。
もし、スケジュール実行で定期的にbatch処理をしたい!とかでれば、lambdaなんかを使ってqueueに送信してやるといいかなぁと思いました。

追記

シェル内にkmsで暗号化したssh keyを含めているのですが、出来れば外出ししたい。。
パラメーターストアとかに出せるかと思ったのですが、文字数制限の関係で無理でした。

続きを読む

2017/3/11 JAWS DAYS 2017 参加メモ

http://jawsdays2017.jaws-ug.jp/

赤ドクロ Presents 『AWSでアプリ開発するなら 知っておくべこと』

https://www.slideshare.net/keisuke69/aws-73040279

アーキテクチャのベストプラクティス

  • Design for failure

    • 単一障害点をなくす、すべてが失敗し得るという前提で考える

      • 最初に1ホストを複数に分割する⇒Webとデータベース(RDS)
      • 複数のWebインスタンスを異なるAZで
      • RDSはMulti-AZ
      • ELBを利用して負荷分散
  • Build Security Every Layer
    • 通信経路および保存されたデータの暗号化、IAM/セキュリティグループ
  • Leverage Many Storage Options
    • 万能なデータストアは存在しない、特性に応じて使い分ける
    • Storage
      • Object Storage: S3, Glacier
      • File/Block Storage: EFS(NFS、共有ディスク), EBS
    • Database
      • NoSQL: ElastiCache, DynamoDB
      • SQL: RDS(トランザクション処理), Redshift(DWH)
      • 静的コンテンツはS3に
      • セッションやステートはDynamoDB
      • DBのキャッシュはElastiCache
  • Implement Elasticity
    • IPアドレスで参照しない(名前ベースで)、分散させる
  • Think Prallel
    • EMRを用いて並列のMapReduceジョブを実行、ELB、1つのKinesis Streamと複数のKCLアプリケーション、バックエンドとしてのLambda
    • 1インスタンスでN時間 = N台を1時間 ⇒ コストは同じ
  • Loose Coupling
    • コンポーネント間の結合度が緩やかになるほど、スケーラビリティは高まる
    • すべてのコンポーネントはブラックボックスとしてデザイン(APIアクセス、DNS名でアクセスなど)
    • Queueを使って疎結合に(部分的なretryがしやすくなる、重たい処理だけをスケールする)
    • Service Discovery
      • 各サービスで増えたリソース、減ったリソースに対して透過的にアクセス
      • Auto Scalingを使ったELB自動登録、Consulなど
    • Asynchronous Integration
      • 同期処理である必要がなければ非同期にする(その処理、本当にレスポンス必要ですか?)
      • アプリケーションがブロックされない
      • スケーラビリティ&高可用性
      • Frontendを停止することになくBackendを容易にメンテナンス可能
      • リクエストの処理順序やリトライ等の制御が容易に(一方、数珠つなぎで全体の見通しは悪くなる)
  • Don’t Fear Constraints
    • より多くのメモリが必要?⇒負荷分散、キャッシュ
    • データベースのIOPSが必要?⇒リードレプリカ、シャーディング、データベースのキャッシング
    • 問題のあるインスタンスを破棄し、置き換える

The Twelve-Factor App

  • Dockerによるアプリケーション開発やLambdaのようなサーバレスコンピュートの普及に伴い、改めて重要性が増しつつある
  • Codebase
    • デプロイされているアプリとコードベースは常に1:1であるべき
  • Dependencies
    • 依存関係を明示的に宣言し分離する
    • 特定の環境に暗黙的にインストールされているパッケージやツールに依存せず、アプリに同梱する
    • 例:gemとbundler
  • Config
    • OSレベルの環境変数によって注入されるべき
    • 設定ファイルは言語/フレームワークの環境依存になる
  • Backing Service
    • ネットワーク越しに使うものはすべてリソースとして扱い(URLのように)、データベースはアタッチされたリソースとして扱う
    • リソースの切替はリソースハンドルの切替(URLの切替)とする
  • Build
    • build、リリース、実行の3つのステージを厳密に分離する
    • すべてのリリースは一意のIDを持つべき(どの環境にどのIDがdeployされているか)
  • Process
    • アプリケーションをStatelessなプロセスの組み合わせとして実行!
    • スケールアウトの単位としてプロセスモデルは分かりやすい(スレッドはメモリ共有するなどで管理が複雑)
    • 永続化する必要のあるデータ(次のリクエストでも利用するデータ)はDBなどstatefullな外部サービスを利用
    • ローカルディスクのファイル、メモリ上のデータはあくまでもキャッシュとして扱う
  • Dsiposability
    • グレースフルシャットダウン
  • Dev/prod parity
    • 開発・ステージング・本番環境をできるだけ一致させ、CI/CDの効果を発揮する
  • Log
    • 出力ストリームの保存先やルーティングにアプリは関与しない(標準出力に吐き出すだけにする)
    • 収集、保存、インデックス化し分析する環境をアプリの外に用意する
  • Stateless
    • ステートフルにになる要素を水平スケールするリソースの外部に配置
    • Session情報(スケールアウトすると新しいインスタンスから見えない)⇒DynamoDBに見にいってローカルにキャッシュ

DevOps

  • 無駄やボトルネックを取り除くことで、ライフサイクル(フィードバックループ)を効率化し、高速化する
  • Cluture:End to EndでOne teamであること、主体的なオーナーシップ、行われた作業の結果に対する可視性を高める
  • Practice:Automate Everything、Test Everything, CI/CD/Infrastructure as a code, etc…
    • 自動化と構成管理:プロビジョニング、設定、オーケストレーション、レポーティング
    • ApplicationとInfrastructureをいずれも、バージョン管理し、build&testし、成果物を登録し、デプロイする
    • 繰り返し継続的に行う
  • Tool

DevOps tool on AWS

  • ほとんどのサービスにAPIが用意されている⇒プログラミングの文脈でインフラを制御する

    • 各言語のSDKが用意されている(IDE向けのプラグインも用意されている)
  • Cloud formation
  • Jenkinsを使ったデプロイ

ベストプラクティス

  • 自動ロールバック:まずはロールバックし、その後ログ/グラフなどを用いてデバッグする
  • ダッシュボードで通常時と異常時を把握する

AWS SECURITY DEATH m/ ~セキュ鮫様からのお告げ~ by Security-JAWS

ネットワーク

  • public subnet / private subnet

    • public subnet: インターネットに直接接続可能なサブネット(公開サーバを置く、EIPとの紐づけもできる)
    • private subnet: NATゲートウェイを経由して内⇒外のインターネット通信は可能
  • statefull / stateless
    • NAT配下のクライアントのSource Portはハイポート(1024-65535)からランダムに設定される
    • Statefull: 戻りの通信もよろしくしてくれる
    • Stateless:内⇒外も書かないといけない(1024-65535/tcp)
    • Security GroupはStatefull⇔Network ACL(subnet単位で通信を制御)はStateless
  • VPN
    • ユースケース

      • Webサーバ/DBサーバのメンテナンスはプライベートネットワーク経由で行いたい(平文でインターネットを通さない)
      • 社内システムで事業所とAWSの間(Direct Connectは品質を高めることもできる)
      • AWSを既存システムの拡張リソースとして使用するような場合(繁忙期など)
    • VPNの場合、AWS側には2つのVPNエンドポイントが用意される(Customer Gateway側で2つのトンネルを張る必要がある)
      • static routingもしくは、BGPによるダイナミックルーティング(対応機種のFAQ参照)
  • Direct Connect(専用線接続)
    • 宅内~接続ポイント⇒一般的には通信キャリア
    • 接続ポイント~AWS⇒AWSが提供
    • VLAN分けをできるキャリアと、できないサービスがある
    • TOKAIコミュニケーションズ、Colt(旧KVH)

WAF/DDoS

  • 全脳アーキテクチャ若手の会
    #### DDoS
  • DDoS対策(コストがかかる)、DDoSをあえて受ける(落ちてもいいサイトであれば、放置するのも一つ)
    • L3/L4:Infrastructure
    • L7: Application
  • AWS Shield
    • CloudFrontを使って、Shieldオプションを有効化
    • Shieldの後ろはAWSでも、オンプレでも対策可能
    • 防御対象:CloudFront, ELB, ALB, Route53
    • 監視:常にモニタリングしてベースラインの作成、異常検出
    • Basicは無料で利用可能、AdvancedはDRT付き
    • Billing Protection
    • DRT:WAFのチューニングやルール作成もやる
    • CloudFrontさえ入っているなら、導入しておかない手はない!

WAF

  • FWやIDS/IPSでは防ぐことができない不正な攻撃を遮断(アプリケーション脆弱性など)

    • PCI-DSS 6.6にもWAF導入について明記されている
  • AWS WAF
    • カスタムルール(IPアドレス制限/文字列制限)、SQLI/XSSといった基本的な対策が可能
    • 構成:CloudFront, ELB, ALBに仕込めるマネージドWAF
    • ルールを正規表現で書けない、WAF検知ログは100件まで
  • AWS WAF / WAF on AWS / SaaS WAF / Cloud WAFの比較
    • SaaS WAF / Cloud WAF: 正常な通信の確認、DNSの向き先変更程度で導入できる
    • WAF on AWSはオートスケールに対応している製品が多い
    • AWS WAFはセキュリティ面では物足りない
  • 「セキュリティ開発」はなぜ浸透しないのか

AWS Config

ごちゃごちゃしやすいAWSリソースを簡単に「見える化」できる

  • 構成管理、変更管理のためのサービス(よく使うサービスは対応済)

    • 構成情報のスナップショットの取得
    • 変更内容を追うことができる、SNSを使った通知も可能
    • AWSリソース間の関係性の確認(EC2とVPC/Security Group/ALBとの関係)
    • EC2 Systems Manager: エージェントを入れると、OSの中の情報を取れる、コンソールからコマンドを発行⇒OS上の変更管理が可能になった
    • IAMの構成管理
  • ユースケース
    • AWSリソースの一覧でAWSリソースを確認できる、削除されたリソースについても追跡可能
    • いつ、どのように変更されたかを記録するので証跡として利用可能
    • 関連するAWSリソースも辿れるのでトラブルシュートしやすい
  • AWS Confing Rules
    • AWS Configで記録した設定が正しいかを判定するルールを定義できる
      • セキュリティグループがフルオープン
      • MFA設定していない
      • ACMの証明書の有効期限があと少し
  • マネージドルール
    • Instanceにtagをつけているか?(billingのために、作った人/プロジェクト名をつける)
    • SecurityGroupがフルオープンになっているか?
  • カスタムルール
    • 判定機構はLambdaで実装⇒極論、修正することもできる
    • awslabsにカスタムルールが公開されている(現在34)
  • AWS Configを有効化して可視化
    • Auto Scalliingで、頻繁にインスタンスの起動/削除をしていなければ、課金額は大きくない

Chat bots with Amazon Lex

  • Amazon Lex:音声/テキスト処理

    • Alexaと同じ技術で提供されている
    • 音声認識+自然言語処理
  • コンポーネント
    • ユーザ入力⇒出力
    • Intents:意図(Utterance/Slots)
    • Fulfillment:処理
  • Utterance
    • Intent(例:RegisteruserForEvent)に対してユーザ入力を紐づける
    • Sample utteranceを複数事前に定義する
    • 反復して学習することによってユーザ入力の言い回しの揺れを吸収(徐々に改善していく)
  • Slot
    • SLOT NAME: eventDate, SLOT TYPE: AMAZON.DATE
    • 12 March 2017 / tomorrowみたいな揺れを吸収できる
  • Fulfilment
    • AWS Lambdaとの統合⇒クライアントにレスポンスを返す
  • 複数のintentをflowにすることで、より自然な対話が可能になる
    • もう少し知りたいですか? ⇒ yes ⇒ 次のintentに繋げる
    • 曖昧な答えの場合は、プロンプトを出す(「”yes”か”no”で答えてください」)
  • Lambdaとの統合
    • Lexがユーザ入力をparseし、intent/slotsを渡してlambdaを起動、lambdaからレスポンスを返す
    • dialogAction:会話の流れをつかさどる(例:ConfirmIntent)
    • facebookの場合、Response cardを返すこともできる(ユーザに選択肢リストを提示)
  • Lambda Functionの実装例
    • switchでintentごとの処理を定義して、1 functionで複数intentを処理
    • LexResponseBuilderでレスポンスをbuild
  • English Onlyでlaunchするが、複数言語をサポートするロードマップ
    • 開発者からAWS Japanへプレッシャーを!
  • 最初はよくテストして、エラーが多いようであればintentを細かく設定するなどの工夫が必要

サーバレスの今と未来

https://www.slideshare.net/YoshidaShingo/serverlessnowandthen

サーバレス

  • パラダイムシフト

    • サーバが要らないということではなく、開発者はサーバについて「考えなくてもよくなる」
    • 2014年末のre:InventにてLambdaの発表
    • 最大の特徴は、課金は使った分だけ(メモリ×時間×実行回数)
  • Function as a Service
    • アーキテクチャにおける責務

      • Stateful >> Stateless
      • 永続データ >> 揮発性
      • バッチ >> イベントドリブン
  • Lambda goes everywhere
    • コンテナベースの実行環境はportabilityが高いので、いろいろなところにデプロイできる
    • Athenaの基盤もLambda
    • Greengrass(AWS IoT)
    • CloudFrontのEdgeの上

代表的なサーバレスアーキテクチャ

  • UIドリブンアプリケーション

    • 認証ロジックをBaaS、DynamoDBにクライアントから直接アクセス、SPA+API Gateway
  • メッセージドリブンアプリケーション
    • オンライン広告システム
    • コンテンツのサムネイル作成(image magicを載せたlambda)
    • ログのストリームプロセッシング(kinesis/kafkaから取って、加工して、S3やDynamoに入れる)

エコシステム

  • プラットフォーム事業者、フレームワークやツール、アプリケーション開発者

    • アプリケーション開発者のノウハウ発信が足りない
    • cloud packの毎日放送事例
  • Serverless framework, Apex, Lamvery, Swagger, AWS Serverless Application Model(SAM), Postman…
  • SAM
    • CloudFormationテンプレートで管理できる
    • lambda, API Gateway, DynamoDBがサポートされている
    • app-spec.yaml -> CloudFormation(codeはS3経由でデプロイされる)

サーバレスだからこそできることをやる

  • 10X Product Development

    • TypeScriptしか書かず、あとは外部のサービスを使っている
    • firebase(auth), Netlify(static site hosting), Cloudinary(画像管理), Algolia(検索)
  • Serverless, NoOpes and the Tooth Fairy
    • 来るサーバーレスな未来では、アプリケーション開発者が運用に責任を持つ
    • プロバイダの技術情報や、内部技術が何に依存しているか理解する
    • 可視性が下がる、自分自身で問題をfixできないし新機能を実装することもできない
    • 売れていないサービスはシャットダウンされるかも
  • 日経新聞事例(紙面ビューアー)
    • 最大18,000回/1分間のinvocation
  • システムをリアクティブに設計する
    • イベントの発火やwebhookなどに対応している周辺のマネージドサービスとうまくつないでいる
    • シンプルなマイクロサービスとして
    • 一度トライアルしておき、いざ活用する前にはまりどころなど判断

SPAの開発の流れ

  • ビュー/アプリ(js)開発

    • ビューの作成
    • テスト駆動でアプリコードを追加(テストがないと、統合時に問題が起こったときの切り分けが困難)
    • 例:jQuery+Jasmine
    • ローカルで開発可能、チーム開発がはじまったらS3で
    • テスト時のブラウザキャッシュに注意(chromeの開発者ツールでdisable cacheするとか)
    • AWSに繋ぐ前に、1行書いたら1行テスト
  • Cognitoを使った認証+フェデレーション
    • 例:Google+
    • Googleで認証してIDが払い出される
    • ブラウザがCognitoにJSでアクセス、CognitoがGoogleに検証、OKであればDynamoDB書き込み権限を払い出す
  • DynamoDBを使ったデータの管理
  • Lambdaでシステム強化
    • DynamoDB直接読み書きでは仕組みとしてできてしまう、「不正なクエリからの保護」(lambdaでvalidationするなど)
    • 「ユーザ全員分の集計」などの情報提供のため
  • Serverless Single Page Apps
    • Ben Rady著、Step by Stepガイド(日本語版が間もなく出る予定)

参考(ところどころで言及されていた別発表)

[AWSワークショップ] Amazon Kinesis Analyticsを触ってみよう

kinesis

  • モチベーション

    • 処理した結果を複数システムに送る必要がある

      • kafka or Kinesis Streams
    • しかも機械学習を行なう
      • Spark Streaming or Storm
  • Kinesis
    • Streams

      • マネージドkafkaのイメージ:入出力に制限はある(入力:秒間1MBまたは1,000put)
    • Firehose:S3, Redshiftへ簡単に配信
    • Analytics:SQLクエリー
  • Stream Source/Destination(StreamかFirehose)
    • 入力側を決定する(Strems or firehouse)
    • 入力データの型定義をおこなう
    • SQL分を作成、デプロイ
    • 出力先を決定する(Strems or firehouse)
  • kinesis demo stremasは良く停止するので注意・・・
    • データ定義は大文字で定義(もしくはselect句をダブルクォーテーションで挟む)

Windowの概念

  • Tumbling Window(例:1分ごとに出力)

    • FLOOR((“SOURCE_SQL_STREAM_001”.ROWTIME – TIMESTAMP ‘1970-01-01 00:00:00’) SECOND / 10 TO SECOND)
    • 10 TO SECOND⇒10秒間隔
  • Sliding Window(データが流れてきたら出力を開始する)
    • Time(60sec:レコード受信をトリガーに直近60sec分を集計)
    • Row(2rows:自分+直近2レコード)
    • 1つのdestinationに対して、TimeとRowを両方設定できる

Reference Dataの追加

  • AWS CLIでのみ追加が可能
  • 例:S3のファイルを見る
  • 現状、Reference Dataを追加すると動作しない(サポート確認中)

まとめ

  • Firehose -> Elastic Search -> KibanaとすべてAWSコンソールで設定可能
  • 構築は非常に楽、標準SQL、Firehoseで接続が簡単
  • バグが多い、性能評価がしにくい
  • kinesis streamsはzookeeperの管理が不要、KPLと併用すれば非常に安い
  • Analyticsは簡単な集計処理ならよいが、複雑な処理はSpark Streaming等を利用したほうがよい

[Alexaハンズオン] Alexa Skills Kit で遊ぼう【基礎編】

続きを読む

rootアカウントに設定したMFAデバイスが時刻ずれした時の再同期方法

はじめに

IAMユーザーのMFAデバイスを再同期する方法はドキュメントに載っている。
http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_sync.html

rootアカウントのMFAデバイスが故障した時の対応も載っている。
http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_lost-or-broken.html

でもrootアカウントのMFAデバイスの再同期の方法が載っていない。(はず)

rootアカウントのMFAデバイス設定はrootアカウントでしかできない。
もちろんコンソール上でrootがroot自身のMFAデバイスを再同期することは可能。

問題はコンソールにサインインする時点で時刻ずれが起こっていた時。
IMAユーザーのMFAデバイスなら、時刻ずれしても、違うユーザーで再同期できるので問題ない。

rootアカウントだと困る。
なので調べました。

1.rootアカウントでサインインを試みる

  • MFAデバイスが設定済みの前提です。
  • https://console.aws.amazon.com/console/
  • メールアドレスとパスワードを入力し、「Sign in using our secure server」で画面遷移。

2.認証コードを入力しないで画面下部のリンクへ飛ぶ

  • 赤枠で囲っている箇所からリンクで飛びます。
  • ちなみに画面上部のエラーは同期がずれてるデバイスで認証コードを生成してサインインしようとした時に(も)出ます。
    • 「There was a pronlem」
    • 「The authentication code you entered is invailid. Please make sure that you have correctly entered your authentication code.」
  • 私の環境だと8ヶ月くらいぶりにデバイスを使おうとしたらずれていました。

rootのMFA再同期1.JPG

3.もう一回アドレスとパスワードを入力する

  • 1.と同じ画面に飛びます。
  • 「あれ?」と思いますが、再度メールアドレスとパスワードを入力し、「Sign in using our secure server」で画面遷移。

4.認証コードを2回入力して再同期

  • MFAデバイスで2回コードを生成し、「Re-sync…」をクリックすれば完了。
  • ちなみに右側の「Contact Us」をクリックすれば、故障時等のサポートページに飛ぶ。

rootのMFA再同期2.JPG

おわりに

物理MFAデバイスは時刻ずれが怖いですね。
仮想MFAデバイスなら大丈夫なものなのかは知りません。

以前行ったOpsJAWSで聞いた話。
ソフトウェアMFAには3種類ある。

  • Saasタイプ
  • モバイルタイプ
  • ローカルアプリタイプ(New!)

某社ではローカルアプリタイプであるWinAuthをEC2上で動かして、
必要時にだけEC2を立ち上げて認証して…という仕組みにしているらしい。
うろ覚えです。

以上です。

続きを読む

[Grafana] Grafanaで、AWSのリザーブドインスタンス(RI)を監視してみた。

こんにちは。
最近開発にも手を出し始めた元インフラのjkkitakita。

とりあえず
何か書きたい衝動に駆られたので
ちょっと前に、遊び感覚でやっていたことをつらつらと。

はじめに

ざっくりでも以下の知識があるとよいかも。

  1. リザーブドインスタンス

  2. Grafana + Influxdb
  3. telegrafのExec Input Pluginについて

各種サービスのバージョン

  • Telegraf – Version 0.10.3
  • InfluxDB shell 0.10.3
  • Grafana v 2.6.0

背景

  1. EC2、RDS、Redshiftの台数が増えてきて、コストが結構かかる。
  2. Trusted Advisorを見れば、現状の最適化は検討できるが、次いつリザーブドを購入すればいいのか把握したい。(cf. 会社のキャッシュフロー)
  3. 現状のオンデマンド/リザーブドの比率をグラフで一目で確認したい。

特に3.が大きい。
「毎月1回、EC2の画面を見て、1日かけて確認する」
的な運用でカバーはまず論外で

その他、頑張ってやろうとすると
– Cost Visualizerを導入する
https://dev.smt.docomo.ne.jp/?p=common_page&p_name=cost_visualizer
– エクセルとかで、毎日編集する

とかって話になって、それはそれで、コスト・手間がかかる。
ぶっちゃけ、これもだるい。めんどくさい。(笑)

めんどくさいなーめんどくさいなーと
ボソボソ言いながら、ふと

「もうサーバーの傾向監視を
telegraf + influxdb + Grafanaでやってるから
RIもそこに入れて、ダッシュボードにしちゃえ!!!!」

ってことで
取り急ぎ、telegraf + bashでいけそうだったので
telegrafの設定開始(`・ω・´)キリッ

telegrafの設定してみる

とりあえず、confにinput.execを追記。

/etc/telegraf/telegraf.conf

# EC2
[[inputs.exec]]
  command = "/etc/telegraf/telegraf.d/exec/count-instances"
  data_format = "influx"
  interval = "3600s"

[[inputs.exec]]
  command = "/etc/telegraf/telegraf.d/exec/reserved_instance.sh"
  data_format = "influx"
  interval = "3600s"

# RDS
[[inputs.exec]]
  command = "/etc/telegraf/telegraf.d/exec/rds_reserved_nodes.sh"
  data_format = "influx"
  interval = "3600s"

# Redshift
[[inputs.exec]]
  command = "/etc/telegraf/telegraf.d/exec/redshift_reserved_nodes.sh"
  data_format = "influx"
  interval = "3600s"

あとは、bashをちょこちょこ書くだけ。

■ EC2
1.全体(オンデマンドとリザーブド)の数

/etc/telegraf/telegraf.d/exec/count-instances.sh
#!/bin/bash

### check instance status is running
/usr/bin/aws ec2 describe-instances --filters "Name=instance-state-name,Values=running" |
jq -r  '[ .Reservations[] | .Instances[] | { InstanceType } ]| group_by(.InstanceType) | .
[]|.[0] + { "Count": length}| .InstanceType, .Count'|sed 'N;s/n/ value=/'|sed 's/^/instan
ces,instance_type=/'

2.リザーブドの数

/etc/telegraf/telegraf.d/exec/reserved_instance.sh
#!/bin/bash

/usr/bin/aws ec2 describe-reserved-instances --filters "Name=state,Values=active" | jq -r
'.ReservedInstances[] | [.InstanceType, .AvailabilityZone, (.InstanceCount|tostring), .End
] | join(",")' | sed 's/T.*//g' | awk -F, '{print "reserved_instances,instance_type=" $1 "
,AvailabilityZone=" $2 ",end_date=" $4 " RI_count=" $3}' | sed 's/=,/=-,/g'

■ RDS
・全体(オンデマンドとリザーブド)とリザーブドの数

/etc/telegraf/telegraf.d/exec/rds_reserved_nodes.sh
#!/bin/bash

# count of rds db instaces group by instance_type
/usr/bin/aws rds describe-db-instances --output json | jq -r '[.DBInstances[] | { DBInstan
ceClass }] | group_by(.DBInstanceClass) | .[] | .[0] + { "Count": length } | [.DBInstanceC
lass, (.Count|tostring)] | join(",")' | sed 's/^/rds_db_instances,db_instance_type=/g'| aw
k -F, '{print $1 "," $2 " values=" $3}'

# count of reserved rds db instances group by instance_type
/usr/bin/aws rds describe-reserved-db-instances --output json | jq -r '.ReservedDBInstance
s[] | select(.State == "active") | [.DBInstanceClass, (.DBInstanceCount|tostring), .StartT
ime] | join(",")' | sed -E 's/^(.*T.*)..*$/1/g' | awk -F, '{print "rds_reserved_instance
s,db_instance_type=" $1 ",start_time=" $3 " RI_count=" $2}'

■ Redshift(dc1.largeのみ)
・全体(オンデマンドとリザーブド)とリザーブドの数

/etc/telegraf/telegraf.d/exec/redshift_reserved_nodes.sh
#!/bin/bash

# count of redshift nodes
/usr/bin/aws redshift describe-clusters --output json | jq -r '[.Clusters[] | select(.Node
Type == "dc1.large") | .NumberOfNodes] | add' | sed 's/^/redshift_cluster_nodes,node_type=
dc1.large values=/g'

# count of reserved redshift nodes
/usr/bin/aws redshift describe-reserved-nodes --output json | jq -r '.ReservedNodes[] | se
lect(.State == "active") | [.NodeType, (.NodeCount|tostring), .StartTime] | join(",")' | s
ed -E 's/^(.*T.*)..*$/1/g' | awk -F, '{print "redshift_reserved_nodes,node_type=" $1 ",s
tart_time=" $3 " RI_count=" $2}'

jq,sed,awkでワンライナーでごり押し。(笑)

もっといい感じにかけるはずだけど
まぁ一旦現状、こんな感じでいけそう。

telegrafの再起動。

/etc/init.d/telegraf restart

InfluxDBの中身確認してみる。
とりあえず、うまくいってそう。

  • EC2

influxdb_instances.png

influxdb_reserved_instances.png

  • RDS

influxdb_rds_instances.png

influxdb_rds_reserved_instances.png

  • Redshift

influxdb_redshift_nodes.png

influxdb_redshift_reserved_nodes.png

Grafanaでダッシュボードつくる

1.各種サービスのリザーブド終了日付を一覧で把握
Grafana_RI_1.png

2.各種サービスのリザーブド数の傾向監視(EC2は、インスタンスタイプ毎)- オンデマンド - リザーブド
Grafana_RI_2.png

お、おう。。。めっちゃコスト削減できそう。。。
とりあえず、私の給料分の何倍かは。。。笑

さいごに

やはり、なんかあったら、Grafanaが一番。笑
特にモニタリングするには。

しかも
Kapatitorとか使えば
AWSサービスとか他のSaaSではできない
詳細なコスト監視も実現できそうなので
本格的に運用する気持ちになったらやってみようと思います!

続きを読む