継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

2年間毎週ブログを書くことで変わったこととコミュニティの存在について考える

ポエム

タダです.

この記事は『write-blog-every-week』のアドベントカレンダー1日目の記事です.

adventar.org

write-blog-every-week とは

『write-blog-every-week』は毎週月曜日から日曜日までの間にブログに目標にしている記事を作っていくこととその記事作成をみんなで後押しする会です. ブログのテーマは問わないことになっています.僕は5月によしたく(id:yoshitaku_jp)さんに誘っていただいて参加させてもらいました.

各メンバーの記事はこのサイトから見ることができるので興味ある人はぜひご覧ください！

このコミュニティに参加する前から僕は週に1度はブログ記事を作ってくことを2年継続しています.今回はブログを書き続けることで変わったことと,継続していくことのコミュニティの存在について考えてみます.

ブログを継続することで変わったこと

ブログを書いて,書いたブログを Twitter でつぶやいたりし続けてきて,初めて会う人から「ブログをよく書いていますよね」と言ってもらう機会が増えました.継続することでブログを書いている人という認識が社内外問わず広がった印象があります.僕がよく書くテーマとして AWS のトピックがあるんですが,AWS を使っている方々が Twitter で言及してもらったり,ブログの読者に登録してもらったりブログをきっかけにたくさんの人と縁ができました.

ブログが多くの人に認識してもらうようになったのは,カック(id:kakku22)さんのブログメンタリングのおかげだと思っています.僕は2019年1月~3月までブログメンタリングをしてもらったのですが,テーマの探し方,記事の深堀の仕方,タイトルのつけ方まで小さなことから大きなことまで幅広く見ていただいたおかげです.僕はカックさんに憧れてブログを続けてきたのですが,カックさんのブログメンタリングも2周年とおっしゃっていました.僕のようにブログを進化させたいと思っている人,技術深耕をサポートしてほしいと思っている方,知名度をあげたいと思っている方はカックさんの胸を借りてみましょう!

継続年数が3年目に入るためAWS 以外の切り口で Python,データ分析,コンテナに関わる発信も力を入れていきブログをきっかけに人との繋がりを広げたいと思っています.

コミュニティの存在

次に,ブログを継続していくことに関するコミュニティの存在についてです.

『write-blog-every-week』は Slack 上でコミュニティメンバーとコミュニケーションをとります.自分が週に何記事書くかを登録しておけば月曜日になった時からブログを書く通知が飛んできます.この通知がいいプレッシャーになります.１人でやっていたら自分のルールを守れなくても何の痛みもないですが,他の人と一緒にやっていることだとそれがいいプレッシャーになって尻を叩かれた気持ちになります.

また,コミュニティーでは記事に対してリアクションをつけたりコメントを入れるといったことやネタ出しに困っている人のサポート,技術的な質問にも回答していたりもします.コミュニティー全体で,ブログを書き続けることの楽しみ,技術を楽しむことに重きを置いたやり取りをする場になっているなと感じます.新しい技術テーマを入れたブログでもっといい刺激をコミュニティーに加えられるように頑張っていきたい所存です 💪

まとめ

ブログを書き続けることと,ブログを定期更新するコミュニティーに所属してみて,その影響を考えてみました.1つのことを続けることと,継続を支援してくれるコミュニティーはとてもありがたい関係で成り立ってるなぁと感じます.ブログもコミュニティーでの活動も2020年も関わって続けていきたいです！

明日は このすみ( id:konosum)さんが担当になります!

関連記事

カックさんとの記事はこちらより！

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

Terraform のバージョンを『v0.11』から『v 0.12 』へアップグレード！

Terraform 運用

タダです.

2019年も残すところ1ヶ月ほど...今年のやり残しは今年のうちに一つずつ片付けたい思いで自分の環境の Terraform のバージョンを v0.11 から v0.12 へアップグレードしたので対応方法を整理しておきます.

www.terraform.io

v0.11 から v0.12 のアップグレードの対処

terraform 0.12checklist コマンド実行の準備

それでは,実際に対処についてまとめていきます.まず,v0.12へ上げるためのプレアップグレードチェックコマンドを実行するためにv0.11.14にバージョンアップします.Terraform のバージョン管理は tfenv で行っています.バージョンアップ後,terraform 0.12checklistを実行してみたらLooks good! We did not detect any problems that ought to be addressed before upgrading to Terraform v0.12 と表示されたので特に問題なくv0.12に上げられることを確認しました.

github.com

$ terraform -v
Terraform v0.11.13

Your version of Terraform is out of date! The latest version
is 0.12.16. You can update by downloading from www.terraform.io/downloads.html

$ tfenv install 0.11.14
[INFO] Installing Terraform v0.11.14
[INFO] Downloading release tarball from https://releases.hashicorp.com/terraform/0.11.14/terraform_0.11.14_darwin_amd64.zip
######################################################################## 100.0%
[INFO] Downloading SHA hash file from https://releases.hashicorp.com/terraform/0.11.14/terraform_0.11.14_SHA256SUMS
tfenv: tfenv-install: [WARN] No keybase install found, skipping GPG signature verification
Archive:  tfenv_download.yGld76/terraform_0.11.14_darwin_amd64.zip
  inflating: /Users/tada/.tfenv/versions/0.11.14/terraform
[INFO] Installation of terraform v0.11.14 successful
[INFO] Switching to v0.11.14
[INFO] Switching completed
$ terraform 0.12checklist
Looks good! We did not detect any problems that ought to be
addressed before upgrading to Terraform v0.12.

This tool is not perfect though, so please check the v0.12 upgrade
guide for additional guidance, and for next steps:
https://www.terraform.io/upgrade-guides/0-12.html

v0.12へモジュールを変更する

v0.11からv0.12への移行は,Terraform のバージョンだけでなく,Terraform のモジュールもv0.12のものに変更する必要があります.まずは,Terraform のバージョンをv0.12へあげます.その後, tf ファイルがあるディレクトリに移動して terraform 0.12upgradeコマンドでモジュールを上書きします.

All other commands: 0.12upgrade Rewrites pre-0.12 module source code for v0.12

tfenv install 0.12.1
[INFO] Installing Terraform v0.12.1
[INFO] Downloading release tarball from https://releases.hashicorp.com/terraform/0.12.1/terraform_0.12.1_darwin_amd64.zip
######################################################################## 100.0%
[INFO] Downloading SHA hash file from https://releases.hashicorp.com/terraform/0.12.1/terraform_0.12.1_SHA256SUMS
tfenv: tfenv-install: [WARN] No keybase install found, skipping GPG signature verification
Archive:  tfenv_download.RQsRDE/terraform_0.12.1_darwin_amd64.zip
  inflating: /Users/tada/.tfenv/versions/0.12.1/terraform
[INFO] Installation of terraform v0.12.1 successful
[INFO] Switching to v0.12.1
[INFO] Switching completed

$ terraform help
Usage: terraform [-version] [-help] <command> [args]

~中略~
All other commands:
    0.12upgrade        Rewrites pre-0.12 module source code for v0.12
~中略~

Terraform のバージョンを上げたので,続いてterraform 0.12upgradeコマンドを実行してみたところError: failed to load provider "aws": Incompatible API version with plugin. Plugin version: 4, Client versions: [5] と Terraform のプラグインでエラーが出ました.こちらに対応していきます.

$ terraform 0.12upgrade

This command will rewrite the configuration files in the given directory so
that they use the new syntax features from Terraform v0.12, and will identify
any constructs that may need to be adjusted for correct operation with
Terraform v0.12.

We recommend using this command in a clean version control work tree, so that
you can easily see the proposed changes as a diff against the latest commit.
If you have uncommited changes already present, we recommend aborting this
command and dealing with them before running this command again.

Would you like to upgrade the module in the current directory?
  Only 'yes' will be accepted to confirm.

  Enter a value: yes

-----------------------------------------------------------------------------

Error: failed to load provider "aws": Incompatible API version with plugin. Plugin version: 4, Client versions: [5]

Terraform プラグインエラーの対応方法

調べてみたところ,$HOME/.terraform/plugins 配下の terraform-provider-aws_xxxのプラグインを削除し,導入し直すコマンドを実行すればエラーを解消できる情報を発見したので試してみたところ,エラーを解消してモジュールのアップグレードも完了しました.

$ rm .terraform/plugins/darwin_amd64/terraform-provider-aws_v2.6.0_x4
$ terraform init -get-plugins=true -reconfigure

Initializing the backend...

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "aws" (hashicorp/aws) 2.39.0...

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
blackeyes01-1875 :: ~/terraform_sample » terraform 0.12upgrade

This command will rewrite the configuration files in the given directory so
that they use the new syntax features from Terraform v0.12, and will identify
any constructs that may need to be adjusted for correct operation with
Terraform v0.12.

We recommend using this command in a clean version control work tree, so that
you can easily see the proposed changes as a diff against the latest commit.
If you have uncommited changes already present, we recommend aborting this
command and dealing with them before running this command again.

Would you like to upgrade the module in the current directory?
  Only 'yes' will be accepted to confirm.

  Enter a value: yes

-----------------------------------------------------------------------------

Upgrade complete!

The configuration files were upgraded successfully. Use your version control
system to review the proposed changes, make any necessary adjustments, and
then commit.

まとめ

Terraform のバージョンを0.11 から 0.12 へアップグレードした時の対処をまとめました.2019年11月27日時点ではバージョンがv0.12.16になっています.v0.12になると以前と変化点もあるため対処方法を確認して対応していきたいですね.この記事で何か参考になることがあれば幸いです！

www.hashicorp.com

最後にTerraform の勉強でお世話になっている『実践Terraform　AWSにおけるシステム設計とベストプラクティス』が安く販売されているようなので検討中の方は今がチャンスです！

実践Terraform　AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）)

実践Terraform　AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）)

関連記事

合わせてこちらの記事もぜひ！

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

データアナリストとデータサイエンティストの登竜門！ 『Data Gateway Talk vol.4』初参加レポート

レポート 勉強会

タダです.

11/21 開催の 「Data Gateway Talk vol.4」にブログ枠として参加させてもらったのでイベントの模様をレポートとして書きます.

data-gateway-talk.connpass.com

今回の会場はレコチョクさんのオフィスでした.社内 BGM がたくさんの曲が流れており音楽好きな僕としてはテンションあがりました! オフィスもとても綺麗✨

f:id:sadayoshi_tada:20191121191305j:plain f:id:sadayoshi_tada:20191121191332j:plain

勉強会の趣旨

勉強会の趣旨は,下記の通りですが最近様々な勉強会が増えたが,ツヨツヨな内容になっていることが多い...そんな背景から若手のデータアナリストやデータサイエンティストの「登竜門(Gateway to Success/成功への第一歩)」になることを目指す勉強会というテーマがとても素敵だなーと思いました.次回以降に僕も登壇していきたい！

Data Gateway Talkはデータアナリスト/データサイエンティストの 登竜門(Gateway to Success)となることを目指した勉強会です。

「LTに登壇してみたかったけど、ちょっと自分はまだ早いなぁ」と思っていた方向けに「LT初登壇枠」を設けております。 この機会にぜひ登壇してみてはいかがでしょうか？

このイベントはこんな方にぴったりです。

・聴講者：他社のデータアナリスト/データサイエンティストが何をやっているかを聞きたい方

・LT初登壇枠：何かしらの勉強会で登壇をしたいと思っていたが、躊躇いがあった方

・ 全員：データアナリスト/データサイエンティスト同士の交流を広めたい方

参考情報 : 登竜門の意味とは？ biz.trans-suite.jp

発表ごとのサマリー

時系列で発表のサマリーと所感をまとめていきます.発表資料はアップロードされているものを載せさせてもらっています.

スポンサー紹介

レコチョクについて by 福治 菜摘美 さん

レコチョクのデータ分析基盤について by 佐藤 俊之 さん

福治 菜摘美 さんから「レコチョクについて」、佐藤 俊之 さんから「 レコチョクのデータ分析基盤について」のお話がありました.今回はデータ分析基盤にフォーカスした内容をサマリーで書きます.

サマリー

  • レコチョクのデータは以下の3つのシステムから収集している
    • 音楽配信サービス
    • 音楽体験サービス
    • 楽曲管理システム
  • レコチョクさんのデータ分析基盤は AWS を採用している
  • バックエンドやフロントエンドから得たデータを S3,Kinesis Data Streams に流し,Redshift へ加工したデータを取り込んでいく.
    • Redshift に入れたデータはBI/分析/レポート出力/レコメンドに使っている
  • データ分析基盤の役割は3つあり,データ収集 / データ加工 /データ活用 となる
  • 現在のデータ基盤と未来のデータ基盤について
    • 現在は,サービス追加以外はほとんどなく定常運用は全て自動化が済んでいる
      • BIツールとして Domo を利用し,他の部署の人もデータを使えるようにしている
    • 今後はデータ分析とデータ活用へ注力していく

若手LT枠

Data Science APIの紹介 by 吉永 尊洸 さん

サマリー

  • LINE の「Data Science API」について
    • 広告サービスのデータアナリストによって開発された API
  • 「Data Science API」とは分析の知見を API(RestAPI) 化して誰でも使えるようにしている
    • モチベーションとして,利用者がデータアナリストを使わなくてもやりたいことに注力できる環境をつくる

*「Data Science API」は Python + FastAPI で開発し,コードを GitHub に PushしたらCIで 静的解析/テスト後デプロイ.デプロイ後はユーザーは利用できる

  • API活用事例
    • Anomaly Detection : 広告KPIの異常がないかを確認している
    • KPI Prediction : BIツールをつかってデイリーで予実レポート配信し、事業管理で活用
  • APIを作ってよかったこと
    • 必要な時に必要なサービスを届けられるようになった
    • 特定な言語の異存はないので横展開しやすい
    • 同じようなコードを書かなくて良くなった
      • 自分たちの仕事を殺すかと思ったら分析者の生産性が向上！
  • 今後は横展開や機能追加・基盤整備を進めたい

発表資料

新サービス立ち上げ時における分析チームの役割 by 田村 壮慶 さん

サマリー

  • データ分析チームの立ち上げの話
    • 今は一人だけどチームと呼ばせてくださいwとおっしゃってましたが、新規プロジェクトで1人チームでいろいろとアクションされてるのはステキです！
    • ミッションは,「プロジェクトをビジョンに向けて推進するために各チームの意思決定をサポートする」
      • 現状把握、仮説検証、改善提案を各チームを行う支援をしていく
  • 役割
    • 1 環境構築と運用；
      • データ活用フローの設計
        • 何故データを集めて何に使いたいのかを決めた
        • 無駄な運用をしないため自動化
      • 運用
        • 取得データは開発者ドキュメントで管理するような運用を行なっている
    • 2 各チームのPDCAサポート
      • ダッシュボードの作成
        • 作業依頼の窓口を統一化するために Slack チャンネルを統一化
      • データドリブンな環境づくりをしていこうとしている

LT初登壇枠

ゲーム会社で求められるデータアナリストの役割 by 金 鎮吾 さん

サマリー

  • 事業会社向けのデータアナリストの役割とは,先頭に立って周りのアクションを起こす人
    • データが使われないとデータアナリストの存在意義が薄くなるので,データ分析+データを活用できるところまで関わりビジネス問題を解決できるまで取り組むことがミッションと捉えている
  • 4つのアプローチでデータアナリストとしてのミッションを実現を目指した
    • 1 ビジネスの問題・課題の明確化
    • 2 関係者の業務の優先度を詳細化
    • 3 受け側のデータリテラシーを考慮する
    • 4 データ活用で成功体験をあたえたり,データリテラシーの向上と連携プロセスを確立し,データ分析の文化を作る

分析案件をやり始めたときに陥っていたことの共有と対策 by 長野 克也 さん

サマリー

  • 何故なんとなく分析してしまうか？
    • モデルの構築手法をどうやって選んだらいいかがわからない
      • 何故その手法が必要なのかを考えて学習する
        • 類似手法との比較,類似手法との違いは何かを理解する
    • モデルを選択後,何について考えればいいのかわからない
      • なぜ選択したのか説明可能な状態にする

発表資料

先輩枠

データアナリストに関する情報収集 by 後藤 亮介 さん

サマリー

  • ZOZO 研究所におけるデータアナリスト の仕事は ファッションを数値化していく仕事で,具体的には以下の業務に携わっている
    • BIツール分析,機械学習システムの設計・実装・評価
    • 新規サービスの ML 部分の相談窓口
    • 論文執筆、雑誌メディアへの寄稿
    • 採用面接への参加
  • 情報収集する理由として以下の理由がある
    • 問題に対する解決手段の選択肢を増やす
    • スケーラブルに仕事をするためにクラウドコンピューティングやマネージドサービスを使って効率的に仕事をする
    • 採用面接で試される
    • 研究者として論文を書くため
  • 後藤さんがよく読んでいるブログメディア
  • サブスクライバしているメルマガ
  • 論文
  • Google News

まとめ

「Data Gateway Talk vol.4」の各発表のサマリーをまとめていきました.自分自身はデータ分析に興味をもって勉強し始めた身ですが,データを生かしてチームの意思決定,プロダクト,事業に関われるところが改めて魅力だと感じました.やはり普段の生活とは異なる世界の話を聞くと刺激をもらえます.知らなかった世界を知れて勉強になりました.今日もらったモチベーションをこれからの勉強の糧にしていきたいです.

発表者の皆さん,運営の皆さん,お疲れ様でした！ 次回も楽しみにしています！！

AWS アカウントを跨いだプライベートホストゾーンの設定方法

AWS Route53 AWSCLI 運用

タダです.

業務で Route53 プライベートホストゾーンを別アカウントの VPC でも使うことができるよう設定を行ったのでどのように設定するかを整理しておきます.

本記事で紹介する設定の概要

まず,Route53 プライベートホストゾーンは VPC に閉じたプライベートネットワーク内の DNS ドメインレコードを管理するためのコンテナになります.プライベートなのでインターネットにリソースを公開せずに名前解決が可能になるのが特徴で,関連づける VPC は複数サポートされています.

docs.aws.amazon.com

下の構成図のようにメインアカウントの Route53 プライベートホストゾーンとサブアカウントの VPC を関連付ける方法をこの記事で紹介します.

f:id:sadayoshi_tada:20191116183151p:plain

同一アカウントでのプライベートホストゾーンの VPC 関連付けは Route53 の管理画面から VPC ID を参照できますが,別アカウントの VPC は下記の引用文にあるように参照できません.そのため,別のアプローチが必要になるのですが,今回は AWS CLI を使った設定方法を紹介します.

次の点に注意してください。

・あるアカウントで作成した複数の VPC と別のアカウントで作成したホストゾーンを関連付ける場合は、VPC ごとに認証リクエストを送信する必要があります。

・関連付けを許可する際、ホストゾーン ID を指定する必要があるため、プライベートホストゾーンが存在している必要があります。

・VPC とプライベートホストゾーンの関連付けを許可する場合や、関連付けを行う場合はいずれも、Route 53 コンソールを使用することはできません。

参考ドキュメント

docs.aws.amazon.com

予め準備しておくこと

予め準備しておくこととして,別アカウントの VPC では DNS ホストゾーンの設定を有効化してください.プライベートホストゾーンの設定に必要な要素となります.

Amazon VPC 設定

プライベートホストゾーンを使用するには、次の Amazon VPC 設定を true に設定する必要があります。

・enableDnsHostnames

・enableDnsSupport

下記の画像のようにDNS hostnames Enabled になっていればOKです.

f:id:sadayoshi_tada:20191116180637p:plain

参考ドキュメント

docs.aws.amazon.com

また,AWS CLI の実行環境とプライベートホストゾーンの管理アカウントと関連づける VPC のアカウントそれぞれのアクセスキーとシークレットアクセスキーが必要です.Route53 の強い権限 AmazonRoute53FullAccess 等を付与ください.今回は,AdministratorAccess を付与して確認しています.

実際の設定作業

それでは,実設定を行います.

1 予めプライベートホストゾーンを管理するアカウントで別アカウントの VPC を関連づける前のホストゾーンの設定状況を確認します.

$ aws route53 get-hosted-zone --id  <プライベートホストゾーンのID>

[実行結果]

{
    "VPCs": [
        {
            "VPCId": "vpc-xxxxxxxxxxxxxxxx",
            "VPCRegion": "ap-northeast-1"
        }
    ],
    "HostedZone": {
        "ResourceRecordSetCount": 2,
        "CallerReference": "xxxx",
        "Config": {
            "Comment": "for test",
            "PrivateZone": true
        },
        "Id": "/hostedzone/<プライベートホストゾーンのID>",
        "Name": "private.hoge.com."
    }

2 以下の AWS CLI コマンドをプライベートホストゾーンを管理するアカウントで実行して,対象のVPCを紐づけます.

$ aws route53 create-vpc-association-authorization \
--hosted-zone-id <プライベートホストゾーンのID> \
--vpc VPCRegion=ap-northeast-1,VPCId=<別アカウントの VPC ID>

[実行結果]

{
    "HostedZoneId": "<プライベートホストゾーンのID>",
    "VPC": {
        "VPCId": "<別アカウントの VPC ID>",
        "VPCRegion": "ap-northeast-1"
    }
}

3 サブアカウントの権限でプライベートホストゾーン管理アカウントに認証リクエストを送ります.

$ aws route53 associate-vpc-with-hosted-zone \
--hosted-zone-id <プライベートホストゾーンのID> \
--vpc VPCRegion=ap-northeast-1,VPCId=<別アカウントの VPC ID>

[実行結果]

{
    "ChangeInfo": {
        "Status": "PENDING",
        "Comment": "",
        "SubmittedAt": "2019-11-16T08:41:16.398Z",
        "Id": "/change/C1I9D47KD29FOR"
    }
}

4 再度プライベートホストゾーンを管理するアカウントでホストゾーンの設定状況を確認します.

$ aws route53 get-hosted-zone --id  <プライベートホストゾーンのID>

[実行結果]

{
    "VPCs": [
        {
            "VPCId": "vpc-xxxxxxxxxxxxxxxx",
            "VPCRegion": "ap-northeast-1"
        },
        {
            "VPCId": "<別のアカウントの VPC ID>", <= 別アカウント VPC ID が追加されています
            "VPCRegion": "ap-northeast-1"
        }
    ],
    "HostedZone": {
        "ResourceRecordSetCount": 2,
        "CallerReference": "xxxx",
        "Config": {
            "Comment": "for test",
            "PrivateZone": true
        },
        "Id": "/hostedzone/<プライベートホストゾーンのID>",
        "Name": "private.hoge.com."
    }
}

管理画面上でも関連づけられていることを確認できました.

f:id:sadayoshi_tada:20191116181804p:plain

まとめ

アカウントが分かれているVPC を Route53 プライベートホストゾーンに関連づける方法で必要な設定をさらいました.なかなかない機会でしたので記事化しましたが,同じ状況の方の参考になれば幸いです.

AWS サービス制限の管理に役立つ『AWS Limit Monitor』の紹介

AWS 運用 AWS ソリューション

タダです.

AWS にはサービスごとに制限が設けられています.EC2 でもオンデマンドインスタンスの制限として vCPU 制限が設けられたのは記憶に新しいです.

AWS サービスの制限 docs.aws.amazon.com

EC2 の起動制限がサーバー台数から vCPU での制限へ変更のアップデート情報を整理する sadayoshi-tada.hatenablog.com

サービス制限の管理には Trusted Advisor や Service Quotas 等のサービスを使って管理することも可能ですが,今回は AWS ソリューションにある「AWS Limit Monitor」というソリューションを紹介します.

aws.amazon.com

AWS Limit Monitor とは

「AWS Limit Monitor」は AWS リソースの利用上限に達しそうになった時に Eメール または Slack に通知を飛ばすことで,利用上限に達する前に制限値を緩和のリクエストをあげる時に役立ちます.

ソリューションのアーキテクチャイメージは以下の通りです.

ソリューション概要の AWS ソリューションの概要ページより引用 f:id:sadayoshi_tada:20191110194823p:plain

当該ソリューションの仕組みは, Trusted Advisor がチェックしている対象のサービス情報を使って利用上限をチェックします.追加でチェックするサービスを増やしたい場合は次のように CloudFormation テンプレート内で設定も可能です.

EventsMap:
   Checks:
     Services:
         '"AutoScaling","CloudFormation","DynamoDB","EBS","EC2","ELB","IAM","Kinesis","RDS","Route53","SES","VPC"'

docs.aws.amazon.com

関連情報

ソリューション概要

aws.amazon.com

ドキュメント

docs.aws.amazon.com

GItHub

github.com

利用方法

利用にあたっては,利用上限をチェックしたいアカウントで CloudFormation テンプレートを実行します.なお,当該ソリューションの CloudFormation テンプレートは バージニアリージョンで展開する必要があるのが注意点です.

CloudFormation テンプレートをデプロイするためには対象のAWSアカウント, Eメールアドレスが必要になるので準備しておいてください. Slack の incoming-webhook の URL と 通知チャンネル名 はオプション設定となるので必要であれば準備ください.

f:id:sadayoshi_tada:20191110201349p:plain

追加のアカウントもあれば別のテンプレートを利用します.このテンプレートをデプロイするためにはメインアカウントのIDが必要なので入力できるようにしておきましょう.

f:id:sadayoshi_tada:20191110205142p:plain

デプロイ後の通知テスト

当該ソリューションのデプロイ後に意図的にサービス上限値に近くなった時の通知テストをしてみました.試しに VPC の作成上限,1アカウントあたり5つまで VPC 作成可能な上限に触れるように VPC を増やしてみたところ Eメール通知がきました.Slack への通知が飛んでいない状況だったので Systems Manager Parameter Store の設定に問題がありそうなため設定を確認してアップデートします...

f:id:sadayoshi_tada:20191110205559p:plain

利用料

当該ソリューションを使うためのコストの参考例があります.1か月あたり約9.50ドル、セカンダリアカウントあたり1か月あたり8.03ドルとなると記載されていたので利用時の参考にしてください.

If you use this solution to monitor vCPU limits, the cost for running this solution in your primary account in US East (N. Virginia) is approximately $9.50 per month, and $8.03 per month per secondary account as of the date of publication.

docs.aws.amazon.com

まとめ

サービス上限の管理ソリューションである「AWS Limit Monitor」を紹介しました.AWS の運用において上限値と付き合って行く必要があります.通常のサービスだけでなく AWS ソリューションを使って素早く実現したいオペレーションの状態にするために利用検討してみてよいかと！ Slack インテグレーション部分は確認出来次第アップデートします 🙇🏻‍♂️