snaqme Engineers Blog

おやつ体験メーカー snaq.me エンジニアによる開発プロダクトブログ

AWS SSO と GSuite を連携した認証のフローを作ってみよう!

こんにちは! SRE を担当している多田です(@tada_infra).

自分の会社では AWS アカウントのログイン形式がこれまでは IAM ユーザーによるアカウントに直ログインになっていたのですが,それを AWS SSO を入れてログイン方式を変更しました.ユーザー管理はデフォルトだと ID 管理が SSO で発行されるユーザーになりますが,業務で GSuite を使っているし,GSuite が IdP として使えるため,AWS SSO の IdP を GSuite で設定する場合の検証をしてみました.次の AWS ブログに手順が載っていたのでその内容に沿って検証したことをまとめます.

aws.amazon.com

aws.amazon.com

設定内容

SSO 側からサービスプロバイダー情報をコピーする

SSO 側の IdP を変更するために ID ソースを選択セクションで外部 ID プロバイダーの項目を選択します.次に,サービスプロバイダー情報のうちAWS SSO サインイン URL,AWS SSO ACS URL,AWS SSO 発行者 URLを控えておきます.

f:id:sadayoshi_tada:20201228060510p:plain f:id:sadayoshi_tada:20201228060818p:plain

GSuite でカスタム SAML アプリケーションを設定する

次に,GSuite 側の設定を行います.GSuite の管理画面に移動し,アプリ>SAMLアプリ>アプリを追加>カスタム SAML アプリの追加を選択します.カスタム SAML アプリの設定ウィザードに則って進みます.まずは,アプリ名ですがこれは任意の名前を入力して次に進みます.

f:id:sadayoshi_tada:20201228150432p:plain

次に,SSO の設定で使うため IdP メタデータをダウンロードして次に進みます. f:id:sadayoshi_tada:20201228150529p:plain

次に,サービスプロパイダの詳細設定を行います.SSO の URL を画像の箇所にコピーして転記していきます.署名付き応答にもチェックを入れて次に進み保存します

f:id:sadayoshi_tada:20201228153618p:plain

最後の属性マッピングは何もせず,完了ボタンを押します.これで GSuite の設定完了です.

f:id:sadayoshi_tada:20201228153909p:plain

SSO 側の連携設定

最後に,SSO と GSuite の連携設定を詰めていきます.はじめに GSuite のカスタム SAML アプリケーション追加設定時にダウンロードしていたメタデータをアップロードします.

f:id:sadayoshi_tada:20201228154223p:plain

アップロードが終わったら最後に確認画面です.ID ソースの変更を承認するのでACCEPTと欄に入力して ID ソースを変更します.問題なければ変更が反映されます.

f:id:sadayoshi_tada:20201228154304p:plain f:id:sadayoshi_tada:20201228154637p:plain

動作確認

最後に動作確認をします.SSO のエンドポイント URL https://XXX.awsapps.com/start にアクセスすると GSuite のユーザー認証に飛びます.

f:id:sadayoshi_tada:20201228154456p:plain f:id:sadayoshi_tada:20201228154738p:plain

ユーザー認証後,設定が問題なければ SSO のログイン後ページに遷移することを確認できました.

f:id:sadayoshi_tada:20201228154920p:plain

まとめ

AWS SSO の IdP として GSuite を設定する検証を行ったのでその内容をまとめました.自分が働く会社では GSuite が業務の中心にありその ID も使うので IdP として投入できれば,入社・退社の手続きでアカウントを消すだけで業務アプリケーションのログイン情報も消せてよく,IAM ユーザーによるログイン管理からも開放されるので効果を感じられました.同様の設定を考えられている方の何か参考になれば幸いです.

関連記事

labs.snaq.me

元記事

元記事はこちらです.

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください!

engineers.snaq.me

AWS Client VPN のユーザー認証を Active Directory 認証で行う

こんにちは! SRE を担当している多田です(@tada_infra).

AWS Client VPN の相互認証を検証した時の課題が VPN 接続ログに誰が VPN を使っているかが記録されてなかったことです.ユーザー認証の仕組みは Active Directory 認証と SAML 認証が用意されているのですが,この記事では Active Directory 認証を試した内容をまとめていきます.

docs.aws.amazon.com

検証シナリオ

シナリオとしては,これまで ACM のサーバー及びクライアント証明書による相互認証だったところを Active Directory 認証の基盤として Simple AD を使って認証するように変更しています.Simple AD を新規に作り,その中で認証するユーザーを作成・管理するような形に変更します.それ以外の設定は変わりません.

f:id:sadayoshi_tada:20201228002910p:plain

設定内容

ユーザー認証設定としてやるのは①Simple AD をプライベートサブネットに作成およびユーザーの作成,②ユーザー認証でエンドポイントの再作成および Client VPN 各種再設定です.

①Simple AD をプライベートサブネットに作成およびユーザーの作成

まず,ユーザー認証基盤である Simple AD の作成とユーザーの作成を行います.ただ,この記事では Client VPN の設定部分にフォーカスするようにしたいため,Simple AD の作成やユーザー作成部分は公式ドキュメントの説明に譲り,割愛します.

docs.aws.amazon.com

②ユーザー認証でエンドポイントの再作成および Client VPN 各種再設定

Client VPN エンドポイントを再作成していきます.変わるのは大きく2カ所です.1つは認証オプションをユーザー認証に設定し,①で作成した Simple AD を指定することと,DNS サーバーの箇所に Simple AD の DNS サーバーの IP アドレス2つを記載することが変わりますが,それ以外は初回の記事と同じ設定で定義しました.また,受信の認証ルールおよびルートテーブルも初回と二回目の記事と同様の設定に行いました.

f:id:sadayoshi_tada:20201228001612p:plain f:id:sadayoshi_tada:20201228001739p:plain

動作確認

エンドポイントの設定が完了後クライアント設定ファイルをダウンロードして VPN クライアントアプリのプロファイルを追加しました.接続を試みるとユーザー認証画面が表示されます.Simple AD の Administrator で認証してみます.

f:id:sadayoshi_tada:20201228002119p:plain

認証が成功し,VPN 接続のログを確認してみたところユーザー名の欄に Administrator が表示されているので意図した通りの設定ができました.

f:id:sadayoshi_tada:20201228002330p:plain

まとめ

Client VPN のユーザー認証方式として Active Directory の認証パターンを試したので検証内容をまとめました.Active Directory 認証パターンも試したのですが,もう1つの SAML 認証パターンも試したいと思っており,AWS SSO との連携をしてみたいと考えているのでその内容は次回以降の記事に書いていきます!

関連記事

labs.snaq.me

labs.snaq.me

元記事

元記事はこちらです.

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください!

engineers.snaq.me

AWS Client VPN の IP アドレスを固定化してインターネットと通信する

こんにちは! SRE を担当している多田です(@tada_infra).

AWS Client VPN 検証の続きです.前回の記事でプライベートサブネットの EC2 への VPN 接続が可能になりました.次に,VPN を繋いだ IP アドレスで業務システムへのアクセス制限をしたいといった要件で検証した内容です.

labs.snaq.me

検証シナリオ

Client VPN が接続できるネットワークと分離した社内のシステム用のネットワークがあると仮定します.要件として ELB + EC2 の業務システムにアクセスできる IP を絞りたいというものがあります.そこで,Client VPN に繋いでインターネットと通信する際は NAT Gateway を経由させることで IP アドレスを固定化します.

f:id:sadayoshi_tada:20201227185255p:plain

パブリックサブネットに Client VPN を関連づけることでインターネットに通信を出すことができますが,接続時にネットワークインターフェースが変わってグローバル IP アドレスも変わってしまうため固定化するために NAT Gateway を使っています.

f:id:sadayoshi_tada:20201227200427p:plainf:id:sadayoshi_tada:20201227200437p:plain

設定内容

前回記事内容に追加する形で設定を行う場合を想定します.やるのは①NAT Gateway をパブリックサブネットに作ってプライベートサブネットのルートテーブルに関連づける,②ルートテーブルと受信の承認ルールの変更する

①NAT Gateway をパブリックサブネットに作ってプライベートサブネットのルートテーブルに関連づける

NAT Gateway を作成し,パブリックサブネットに作ります.作成後,パブリックサブネットが使っているルートテーブルに関連づけます.設定の詳細は下記の解説ページに譲り割愛します.

aws.amazon.com

②ルートテーブルと受信の承認ルールの変更する

受信の承認ルールに0.0.0.0/0 の許可を追加します.ルートテーブルにも同様に0.0.0.0/0 の経路を追加します.

f:id:sadayoshi_tada:20201227203227p:plain

f:id:sadayoshi_tada:20201227203454p:plain

動作確認

NAT Gateway を経由できているのであれば,インターネットに接続できて EIP のアドレスで通信するはずです.検証用に NAT Gateway には 3.113.152.210 を EIP を設定しているので, 使用中の IP アドレス確認をしてみます.

意図通りの設定ができていることを確認できました.

f:id:sadayoshi_tada:20201227203856p:plain

まとめ

今回は,Client VPN を使いつつ IP アドレスの固定化を行ってみました.相互認証での検証は以上になるのですが,相互認証方式だと1つ課題があります.それは接続のログにユーザー名が表示されないことです.この課題を次の記事でユーザー認証方式に切り替えた内容でまとめます.

f:id:sadayoshi_tada:20201227204212p:plain

元記事

元記事はこちらです.

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください!

engineers.snaq.me

プライベートサブネットのサーバー接続をするために AWS Client VPN を使ってみる

こんにちは! SRE を担当している多田です(@tada_infra).

リモートワークが広がる中で AWS Client VPN を使って各種業務システムへの接続を検証する必要があり,AWS Client VPN を検証したので何記事かに分けて検証した内容をまとめます.この記事で Get Started な内容を書いていきます.既に同様の内容の記事は多くあるのですが,やった内容整理するために記事を書きます.

AWS Client VPN とは

AWS Client VPN は下記引用文のようなサービスです.Client VPN 登場前はインターネット VPN のためにサーバーを用意する必要がありましたが,それが無くなりマネージドサービスして提供されているためスピーディーに使えてかつサーバー運用不要なところがいいなと思っています.

AWS Client VPN は、AWS リソースやオンプレミスネットワーク内のリソースに安全にアクセスできるようにする、クライアントベースのマネージド VPN サービスです。クライアント VPN を使用すると、OpenVPN ベースの VPN クライアントを使用して、どこからでもリソースにアクセスできます。

docs.aws.amazon.com

課金体系

Client VPN の課金対象となるのが下記の2項目です.

課金項目 課金額
AWS Client VPN エンドポイントアソシエーション $0.15/時間
AWS Client VPN 接続 $0.05/時

aws.amazon.com

AWS Client VPN を使ってプライベートネットワークにある EC2 に接続する

検証のシナリオとしてプライベートサブネットにある EC2 に Client VPN を使って接続してみます.

f:id:sadayoshi_tada:20201227143437p:plain

Client VPN では認証方式が3つあり,AD 認証,SAML 認証,相互認証があります.今回は相互認証,サーバーとクライアント間で証明書認証を行います.証明書は ACM に登録しておきます.

相互認証では、クライアント VPN は証明書を使用してクライアントとサーバー間の認証を実行します。証明書とは、認証機関 (CA) によって発行された識別用デジタル形式です。クライアントがクライアント VPN エンドポイントに接続を試みると、サーバーはクライアント証明書を使用してクライアントを認証します。サーバー証明書とキー、および少なくとも 1 つのクライアント証明書とキーを作成する必要があります。

サーバーおよびクライアント証明書とキーの生成

サーバーおよびクライアント証明書とキーの作成を行いますが,ドキュメントに記載のフローで対応してきます.キーの作成には easy-rsa を使用します.

docs.aws.amazon.com

$ git clone https://github.com/OpenVPN/easy-rsa.git
$ cd easy-rsa/easyrsa3
$ ./easyrsa init-pki #PKI 環境を初期化
init-pki complete; you may now create a CA or requests.
Your newly created PKI dir is: /XXXX/XXXX/easy-rsa/easyrsa3/pki

$ ./easyrsa build-ca nopass #新しい認証機関 (CA) を構築
Using SSL: openssl LibreSSL 2.8.3
Generating RSA private key, 2048 bit long modulus
......................................................................................+++
..............................................+++
e is 65537 (0x10001)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:awsclient-vpn #任意の名前を入力

CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
/XXXX/XXXX/easy-rsa/easyrsa3/pki/ca.crt


$ ./easyrsa build-server-full server nopass #
Using SSL: openssl LibreSSL 2.8.3
Generating a 2048 bit RSA private key
................................................+++
.............................................................+++
writing new private key to '/XXXX/XXXX/easy-rsa/easyrsa3/pki/easy-rsa-12050.LbZL9a/tmp.B8ySWj'
-----
Using configuration from /XXXX/XXXX/easy-rsa/easyrsa3/pki/easy-rsa-12050.LbZL9a/tmp.EXwFe7
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'server'
Certificate is to be certified until Mar 26 06:03:31 2023 GMT (825 days)

Write out database with 1 new entries
Data Base Updated

$ ./easyrsa build-client-full client1.domain.tld nopass
Using SSL: openssl LibreSSL 2.8.3
Generating a 2048 bit RSA private key
....+++
............................+++
writing new private key to '/XXXX/XXXX/easy-rsa/easyrsa3/pki/easy-rsa-10663.vj9o3i/tmp.7GLYfD'
-----
Using configuration from /XXXX/XXXX/easy-rsa/easyrsa3/pki/easy-rsa-10663.vj9o3i/tmp.TXc5fX
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'client1.domain.tld'
Certificate is to be certified until Mar 26 04:03:38 2023 GMT (825 days)

Write out database with 1 new entries
Data Base Updated

# 専用のカスタムフォルダーにサーバー及びクライアント証明書をコピーする
$ mkdir ~/client_vpn/
$ cp pki/ca.crt ~/client_vpn/
$ cp pki/issued/server.crt ~/client_vpn/
$ cp pki/private/server.key ~/client_vpn/
$ cp pki/issued/client1.domain.tld.crt ~/client_vpn
$ cp pki/private/client1.domain.tld.key ~/client_vpn/
$ cd ~/client_vpn/

証明書の ACM へのインポート

作成した証明書を ACM にインポートします.サーバー証明書とクライアント証明書をインポートします.コマンドがうまくいかない場合は画面から直接インポートでも証明書の登録可能です.

$ aws acm import-certificate --certificate fileb://server.crt --private-key fileb://server.key --certificate-chain fileb://ca.crt --region ap-northeast-1
$ aws acm import-certificate --certificate fileb://client1.domain.tld.crt --private-key fileb://client1.domain.tld.key --certificate-chain fileb://ca.crt --region ap-northeast-1

f:id:sadayoshi_tada:20201227091556p:plain

AWS Client VPN 設定を行う

Client VPN を使うための設定を行います.やるのは①クライアント VPN エンドポイント作成,②クライアントの VPN 接続の有効化,③クライアントのネットワークへのアクセスの承認です.

①クライアント VPN エンドポイント作成

クライアントが Client VPN との接続を確立するエンドポイントを作成します.IPアドレスの CIDR は /12~/22 の範囲で指定が必要です.検証用途のため一番小さいサイズで指定しています.また,ACM にインポートしたサーバー及びクライアント証明書を指定します.

IP アドレス範囲は、ターゲットネットワークまたはクライアント VPN エンドポイントに関連するいずれかのルートと重複できません。クライアント CIDR は、/12~/22 の範囲のブロックサイズが必要で、VPC CIDR またはルートテーブル内のその他のルートと重複できません。クライアント VPN エンドポイントの作成後にクライアント CIDR を変更することはできません。

f:id:sadayoshi_tada:20201227153102p:plain

残りとして関連するエンドポイントを紐付ける VPC とセキュリティグループを指定し,それ以外はデフォルト値でエンドポイントの作成を行います.

f:id:sadayoshi_tada:20201227153131p:plain

②クライアントの VPN 接続の有効化

次に,クライアントの VPN 接続の有効化を行います.エンドポイントと関連づけるサブネットを指定します.これでエンドポイントが有効化ステータスに遷移したり,ルートテーブルへの設定変更やセキュリティグループの関連付けが行われます.

f:id:sadayoshi_tada:20201227154839p:plain

クライアント VPN エンドポイントの状態が available に変わります。これで、クライアントは VPN 接続を確立できるようになりましたが、認証ルールを追加するまで VPC 内のリソースにアクセスすることはできません。

VPC のローカルルートは、クライアント VPN エンドポイントルートテーブルに自動的に追加されます。

VPC のデフォルトのセキュリティグループが、サブネットの関連付けに自動的に適用されます。

しばらくエンドポイント有効化までに時間を要するので待ちます.

f:id:sadayoshi_tada:20201227154155p:plain

③クライアントのネットワークへのアクセスの承認

そして,クライアントのネットワークへのアクセスの承認を行います.クライアントがアクセスできるサブネットの承認ルールを作成します.ユーザーは誰でもつなげるようにしておき,接続できるネットワークは EC2 がいる VPC の CIDR ブロックを指定しています.

f:id:sadayoshi_tada:20201227155851p:plain

VPN クライアント端末のセットアップ

Client VPN の設定は以上で,次に VPN クライアント側の設定をします.やるのは①クライアントアプリのインストール,②Client VPN 設定の取り込みです.

①クライアントアプリのインストール

AWS から専用のクライアントアプリが Windows/Mac それぞれで提供されているので下記のサイトからダウンロード,インストールします.

aws.amazon.com

自分は Mac なのでアプリケーションアイコンとして次のものができていました.

f:id:sadayoshi_tada:20201227160402p:plain

②Client VPN 設定の取り込み

次に,Client VPN 設定の取り込みを行います.Client VPN 画面から クライアント設定のダウンロード ボタンから設定ファイルをダウンロードすると,downloaded-client-config.ovpn というファイルが保存されます.ダウンロードしたファイルをエディターで開き,末尾にクライアント証明書の情報を転記します.

<cert>
Contents of client certificate (.crt) file
</cert>

<key>
Contents of private key (.key) file
</key>

VPN クライアントに設定ファイルを取り込むためにはプロファイルを管理 > プロファイルを追加 していきます.接続名は任意のもの(今回は test というプロファイル名にしました)にし,VPN 設定ファイルはダウンロードした設定ファイルを指定します.これで AWS との接続する準備が整いました.

f:id:sadayoshi_tada:20201227160728p:plain

サーバーへの接続テスト

いよいよプライベートサブネットのサーバーに繋いでみます.サーバーの IP アドレスは XXX.XXX.2.163になります.VPN を経由して SSH で繋いでみましょう.VPN 接続後に端末の IP アドレスを確認すると Client VPN エンドポイントに割り当てたネットワークのアドレスが振られていました.

f:id:sadayoshi_tada:20201227161341p:plain

% ifconfig
~中略~
utun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
    inet XXX.XXX.0.2 --> XXX.XXX.0.2 netmask 0xffffffe0

そして,対象のサーバーにも SSH できました!

 % ssh -i .ssh/XXX.pem XXX@XXX.XXX.2.163

Last login: Mon Dec 21 07:04:45 2020 from XXX.XXX.2.45
XXX@ip-XXX-XXX-2-163:~$
XXX@ip-XXX-XXX-2-163:~$ exit

まとめ

まずは Client VPN をつかってプライベートサブネットの EC2 に接続することをやりました.次は Client VPN をプライベートサブネットにある EC2 にもつなぎつつ他システムで IP アドレスを制御するためグローバル IP アドレスを付与しつつ Client VPN を使う検証を行った内容をまとめます.

元記事

元記事はこちらです.

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください!

engineers.snaq.me

microCMS + Nuxt.js + Vue.js のコンテンツを GitHub Actions でビルド&デプロイする

こんにちは! SRE を担当している多田です(@tada_infra).

microCMS + Nuxt.js + Vue.js のコンテンツを GitHub Actions を使ってビルド,S3 にコンテンツを配備する設定を行いました.また,コンテンツが更新された時にも自動でデプロイされるような設定も行ったので振り返り目的で各設定についてまとめていきます.

GitHub Actions の定義

まず,GitHub Actions の定義部分です.やっている処理は S3 にアップロードするためのアクセスキーとシークレットアクセスキーを設定 -> ビルド -> S3 にコンテンツを同期しています.また,アクセスキーとシークレットアクセスキー,S3 へのパスを GitHub Secrets に設定しています.これで GitHub の特定ブランチにコードがプッシュされたら自動でビルド,S3 にコンテンツ配備されるよう設定できました.

jobs:
    build:
        name: Build & Deploy
        runs-on: ubuntu-latest

        steps:
            - name: Checkout
              uses: actions/checkout@v2
            
            - name: Configure AWS credentials
              uses: aws-actions/configure-aws-credentials@v1
              with:
                aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
                aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
                aws-region: ap-northeast-1

            - name: Build
              run: |
                yarn install 
                yarn build
                yarn generate
            - name:  Contents sync to s3
              run: |
                aws s3 sync [contents path] ${{ secrets.S3_PATH }} 

参考情報

docs.github.com

microCMS 設定部分

次に,microCMS 設定です.microCMS のコンテンツを更新が走った時に自動でGitHub Actions が自動ビルド,デプロイするように設定していきます.管理画面の API 設定 > Webhook > GitHub Actions を選択し,下記の画面の設定を行いました.

f:id:sadayoshi_tada:20201218113117p:plain

GitHub Actions 定義

microCMS 側の設定後 GitHub Actions 側も設定を追加しています.GitHub Actions の定義でrepository_dispatch を指定して microCMS の記事が更新,削除されたりした時 update_post イベントが発行されてくるので そのイベントをトリガーに GitHub Actions が動くように設定しました.これで記事を更新したら自動でビルド,デプロイするようになりました.

on:
~中略~
    repository_dispatch:
      types: [update_post]

参考情報

docs.github.com

まとめ

microCMS + Nuxt.js + Vue.js のコンテンツを GitHub Actions を使ってビルド,S3 にコンテンツを配備するための設定を行ったのでその内容を振り返ってまとめました.設定自体は比較的簡単にできるけれど自動ビルド,デプロイされるのは非常にありがたいです.同様の設定する方の参考になれば嬉しいです.

元記事

元記事はこちらです.

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください!

engineers.snaq.me

redash のアラート機能を使って Slack に通知する設定を試した

こんにちは! SRE を担当している多田です(@tada_infra).

データの可視化を redash で実現する中で特定のデータが閾値に達した時に Slack に通知して欲しいといった要件があり,redash のアラート機能をその要件に合うものかを検証してみたのでこの記事に検証した内容を整理してきます.

検証で使った環境

検証で使った環境は redash の AMI を使っています.東京リージョンのものを使ったので ami-060741a96307668be を指定しています.

redash.io

redash アラート機能設定

今回のケースではデータがリアルタイムで更新される社内システムがあり,そのデータを redash からクエリを発行して見たいといった条件を想定した検証しています.検証した内容にフォーカスするため redash の初期セットアップやデータソース,アラートに関連するクエリ結果の事前設定は割愛し,設定済み前提でアラート機能を使うために設定した内容を以下では書きます.

Slack の設定

まず,アラート発生後の通知先として Slack に通知したいので Slack の設定からです.Settings > Alert Destinations > New Alert Destinationから Slack を選択します. f:id:sadayoshi_tada:20201215054654p:plain

次に, Slack 自体の設定ですが設定名と Incoming Webhook URL を設定しました. f:id:sadayoshi_tada:20201215054708p:plain

以上でアラート先の設定自体は完了です.

アラート設定

そして,アラート設定に移っていきます.上部メニューのCreate > Alert を選択します.

  1. 最初にQuery 欄に事前定義したアラートに関連するクエリを選択します.
  2. 次にアラート通知したい結果が入っているカラムを指定します.
  3. そして,アラートの条件を指定していきます.今回は Value が 100 以下になった時にアラートを出すよう設定しています.
  4. 最後に先ほど指定した Slack の設定を通知先から選んで Add で追加し,Save ボタンで保存します.

f:id:sadayoshi_tada:20201215055531p:plain

以上でアラート設定が完了です.

Slack への通知結果

あとはデータが閾値に達するまで待つだけですが,閾値に達した時に以下の画像のように通知されます.このような形で Slack へのアラート投稿ができました.

f:id:sadayoshi_tada:20201215060504p:plain

設定中に感じた注意点

設定自体は完了なのですが,redash のアラート設定を試して感じた注意点を最後にまとめます.

  • アラート通知できる条件で指定できる値は1つだけなので,クエリ結果で複数レコードが返る場合1レコードしか返らないようにしないと意図したアラートは発行が難しい
  • 画面上で確認する限り条件分岐ができるわけではなさそうなので複雑な処理する場合はコードで制御が必要になると思われる

まとめ

redash のアラート機能で Slack 通知する設定を検証したのでまとめました.クエリの結果を1つに絞れればリアルタイムでコードを書くことなく通知できたのは手軽に設定できてよかったなという感覚でした.

元記事

元記事はこちらです.

最後に

そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください!

engineers.snaq.me

Auto Scaling の AMI に Mackerel Agent を導入する時の設定でハマったこと

こんにちは! SRE を担当している多田です(@tada_infra).

Auto Scaling の EC2 に Mackerel を入れて監視をしたい時にベースの AMI にMackerel Agent を導入します.今回初歩的な躓きだったのですが,Auto Scaling が起動した時に Mackerel で監視できるはずが監視情報が確認できずにいたのを解消したのでその対処を記事にまとめます.

Auto Scaling の時の Mackerel 設定

Mackerel を Auto Scaling 環境で使う時の設定は下記のドキュメントに記載があります.

mackerel.io

Auto Scaling 向けの作業としてやらなきゃいけない設定は2点あります.まず, /etc/mackerel-agent/mackerel-agent.conf でホスト起動時のステータス設定です.Auto Scaling で起動してきた時のホストを自動で監視できるようにするために推奨されている設定です.個人的には加えて設定するロールが決まっていれば合わせて roles の定義も入れておくと Mackerel の登録時にホストだけでなくロールの設定もされた状態になるので,オススメです.

$ cat /etc/mackerel-agent/mackerel-agent.con
~中略~
roles = ["サービス名:ロール名"]

[host_status]
on_start = "working"

次に,ホストが Auto Scaling からホストが削除される時に Mackerel からも自動退役してもらう設定です.自分が扱った環境は /etc/sysconfig/mackerel-agentAUTO_RETIREMENT=1 を追加してます.

$ cat /etc/sysconfig/mackerel-agent
# OTHER_OPTS=-v
AUTO_RETIREMENT=1

以上2点で自動登録と自動退役の設定ができた状態になったので,自分はこの時点で AMI を作っていました.

ハマった事象とその対処

ここまでの設定で Auto Scaling を起動した際に自分の環境では,Mackerel にホストは認識されるけど,サーバー上の CPU,メモリ,ディスクといったメトリクスが表示されてない状態になっていました.Mackerel サポートの方々に協力いただき,Mackerel Agent の起動時のメッセージを確認したところ API request failed: Host Already Retired というメッセージがでていました.Mackerel 側で既に退役済みのホストとしてなっておりメトリックのデータ送信が行われてない場合のメッセージになっていました.この原因は /var/lib/mackerel-agent/id ファイルが存在した状態でAMI 化してしまったため発生しました.

対処内容

/var/lib/mackerel-agent/idは Mackerel 側でホストを一意に識別するためのファイルであり,このファイルがある状態で Auto Scaling で起動した EC2 はもう退役している扱いになってしまいます.そのため,AMI 化する前に /var/lib/mackerel-agent/idを削除しておく,もしくはファイルを退避させる必要があり,今回は削除して AMI 化したところ意図通りメトリクスを確認できるようになりました.

ドキュメント引用文

Mackerel では、管理対象のホストを一意に識別するために、各ホスト毎に「ホストID」を発行し、それに関連付ける形で管理をしています(参照)。 このID情報は、Linux系OSのホストであれば「/var/lib/mackerel-agent/id」ファイルに、Windows OS の場合はインストールフォルダ内の「id」ファイルに、記録されています。

オートスケールによるスケールアウト時に起動させるインスタンスのベースイメージとして、mackerel-agent がインストール済みのカスタムマシンイメージを作成する際には、このホストIDを記録したファイルが含まれた状態でイメージ化をしないよう、注意してください。 (削除せずにイメージ化し、それを元にスケールアウトがおこなわれた場合、Mackerel は起動した全てのサーバを同一のサーバとして識別します。)

mackerel.io

まとめ

Auto Scaling 環境での Mackerel Agent 導入でハマったことを整理しました.ドキュメントの見落としが原因でハマっていたのですが,Mackerel サポートの方々に調査にご協力いただいたおかげで早急に解決に至りました!ありがとうございました🙇‍♂️ 自分と同じ間違いをする方が増えないよう自戒を込めて記事化します.

元記事

元記事はこちらです.