snaqme Engineers Blog

おやつ体験メーカー 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 サポートの方々に調査にご協力いただいたおかげで早急に解決に至りました!ありがとうございました🙇‍♂️ 自分と同じ間違いをする方が増えないよう自戒を込めて記事化します.

元記事

元記事はこちらです.

Mackerel 導入から導入後にやったこととこれからのことを整理する

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

この記事は Mackerelアドベントカレンダー2020の7日目の記事です.皆さんにとって2020年はどんな1年でしたか?いろんなことが変化した1年だったんじゃないかなと思いますが,自分も働き方や9月に会社が変わった1年でした.転職して始めた取り組みとして監視周りがあり,組織内の課題から Mackerel の導入と組織内の方針を決めたりしていきました.そんな Mackerel 導入とその後を振り返っていきたいと思います.

Mackerel の導入前の監視

Mackerel 導入前の監視は CloudWatch で AWS サービスのみを監視しており,EC2 や Aurora などのパフォーマンスに影響があるところを下記のスライドのように Slack にアラート通知している状況でした.

ただ,アラートが鳴っても誰がどんなアクションを起こすのかが不明だったり,開発者もアラート通知チャンネルに入っているが何をしていいかわからないという状況でした.また,サービス提供している部分の中には監視が間に合っていないところがありました.そのため,CloudWatch の監視に加えて外部の監視サービスを検討することになりました.いくつか選択肢がありますが,コストや扱うシステムの監視を賄える物を検討して,最終的に Mackerel を導入することにしています.

Mackerel の導入後にやったこと

Mackerel を導入することになり,自分が取りまとめて検証と組織展開していくためにいくつかの取り組みを行ったのでそれを紹介してきます.

1. Mackerel で監視する箇所の特定とドキュメント化

まずは,Mackerel で監視する箇所の特定を行っていきました.自分が所属する会社では toC 向けのサービスを提供しているのですが,外型監視ができていなくてよくある証明書の有効期限が切れてアクセスできない事象も転職してすぐに起こっていました.なので,ユーザーに最も近いところから監視の設定をいれてきました.また,それらを GitHub にドキュメント化しました.GitHub においたのは今後開発者に開発だけでなく自分たちが開発したシステムの監視に介入してもらい,監視設定を変更したい場合に開発者からプルリクをあげてもらい自分がレビューするといったフローにしていくための意図でやってます.

f:id:sadayoshi_tada:20201206092339p:plain

2. アラート発生時に開発者が担当するシステムごとに対応内容と対応者の明記

次に,開発者ごとで担当しているシステム領域が異なるのでそれぞれの担当領域のアラートを Slack でメンションし,アラートごとにどんな対応をするかを定義して開発者と認識合わせを行いました.Mackerel 導入前アラートは Slack の @channel で通知されるもののアラートがなっていても誰もどんなアクションを起こしていいのかがわからない状態になっていたので,誰がどんな対応をするかを明らかにする必要がありました.これによってこれまで疎遠だった開発者をシステム監視の領域に踏み込んでもらえるようになったと思います.

Mackerel からのアラート通知例 f:id:sadayoshi_tada:20201206092012p:plain

f:id:sadayoshi_tada:20201206092212p:plain

アラートごとの対応内容の一部抜粋 f:id:sadayoshi_tada:20201206150831p:plain

3. 障害対応テンプレートの策定

システムごとのアラートと対応者,対応内容が決まったので組織的に障害発生から障害対応完了,その後の振り返りまでのアクションリストをまとめた障害対応テンプレートを作りました.会社ではドキュメントを esa を使っているので esa に対応内容をまとめています.この定義を行って障害発生時にどう動いて,障害対応後どう動くかを整理することができたと思います.ただ後述しますが,テンプレートを実際に使う機会が日常業務ではアラートが頻発したり,高負荷なシステムが今のところないので,予防訓練でこのテンプレートを使って障害対応を練習していきたいと考えています.

障害対応テンプレートの一部抜粋 f:id:sadayoshi_tada:20201206094323p:plain

これからやっていきたいこと

Mackerel を導入し,運用するに当たって決め事や障害発生時の対応フローが決まりましたが,今後やっていきたいこともあります.

  1. 障害対応訓練
  2. オンコール対応フローの構築
  3. Mackerel ならではの機能の活用

1. 障害対応訓練

1つ目は障害対応訓練です.入社当初は1アカウント本番環境しかなかったのでやり辛さがありましたが,用途ごとにアカウントを分離しております.分離できたアカウントで開発者と障害対応訓練をやっていき,障害対応テンプレートを使ってそれぞれがやるべきことを確認していきたいと考えてます.

sadayoshi-tada.hatenablog.com

2. オンコール対応フローの構築

2つ目はシステム規模が大きくなっていた時にオンコール対応フローの構築です.今今はシステム規模的にも日々の負荷的にもそこまで大きいものではないのでオンコール対応の構築はまだ行っていないのですが,事業のスケールと合わせてシステムもより信頼度の向上を行うためにもオンコール対応フローを構築していきたいです.

3. Mackerel ならではの機能の活用

今は Mackerel Agent で標準利用可能なサーバーからのメトリックと EC2 ではプロセスの監視を行っているほどですが,Mackerel ならではのプラグインの開発や EventBridge と連携して自動復旧の仕組みを作ってみたいとも考えてます.

blog.a-know.me

mackerel.io

まとめ

Mackerel を導入したやったこととこれからやっていきたいことを書きました.監視をエージェント入れてから即座に始められたおかげで今まで見えなかったものがデータとして関係者全員が見えてくるようになって改善や運用業務でアクションがしやすくなりました.今後も Mackerel を活用して自社でのよりよい運用のあり方を追求していきたいです.

元記事

元記事はこちらです.

CloudWatch Agent で procstat プラグインを使った EC2 のプロセス監視を設定する

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

CloudWatch Agent は EC2 から CPU,メモリなどのメトリクスをとったり,CloudWatch Logs にログを出力できますし,AWS Compute Optimizer を有効活用するためにも役立てることができます.今回は,procstat プラグインを使って Nginx のプロセス監視できるように CloudWatch メトリクスに送る検証をしました.多くの方が CloudWatch Agent でのプロセス監視設定を記事にされているのですが,自分も試してみたため記事にします.

CloudWatch Agent の導入

予め CloudWatchAgentServerPolicy をアタッチした IAM ロールを適用した Amazon Linux 2 の環境に CloudWatch Agent を導入します.

sudo yum install amazon-cloudwatch-agent

プロセス数を設定ファイルを編集する

手動で設定ファイルを定義し,CloudWatch メトリクスをおくります.

docs.aws.amazon.com

/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.jsonを編集してきます.

{
    "metrics": {
        "metrics_collected": {
            "procstat": [
                {
                    "exe": "nginx",
                    "measurement": [
                        "pid_count"
                    ],
                    "metrics_collection_interval": 60
                }
            ]
        }
    }
}

編集後,CloudWatch Agent に設定ファイルを読み込ませます./opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.tomlinputs.procstat セクションが追加されていて,CloudWatch Agent が起動できていれば CloudWatch メトリクスに送れているはずなので確認してきます.

$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl  -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json -s

/opt/aws/amazon-cloudwatch-agent/bin/config-downloader --output-dir /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d --download-source file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json --mode ec2 --config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml --multi-config default
Successfully fetched the config and saved in /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_amazon-cloudwatch-agent.json.tmp
Start configuration validation...
/opt/aws/amazon-cloudwatch-agent/bin/config-translator --input /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json --input-dir /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d --output /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml --mode ec2 --config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml --multi-config default
2020/11/26 23:02:31 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_amazon-cloudwatch-agent.json.tmp ...
Valid Json input schema.
I! Detecting runasuser...
No csm configuration found.
No log configuration found.
Configuration validation first phase succeeded
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -schematest -config /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml
Configuration validation second phase succeeded
Configuration validation succeeded
Redirecting to /bin/systemctl stop amazon-cloudwatch-agent.service
Redirecting to /bin/systemctl restart amazon-cloudwatch-agent.service
$ cat /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml
~中略~
[inputs]

  [[inputs.procstat]]
    exe = "nginx"
    fieldpass = ["pid_count"]
    interval = "60s"
    pid_finder = "native"
    tagexclude = ["user", "result"]
    [inputs.procstat.tags]
      metricPath = "metrics"
~中略~
$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
{
  "status": "running",
  "starttime": "2020-11-26T23:02:31+0000",
  "version": "1.247345.35"
}

CloudWatch メトリクスにプロセスが取れているかの確認

CWAgentexe,host,pid_finder というメトリクス(プロセスに関連付けられたプロセス ID の数)が追加されてました.意図的に nginx を停止,再度起動してグラフが上がっていくのを確認できました.

f:id:sadayoshi_tada:20201127081621p:plain f:id:sadayoshi_tada:20201127081739p:plain

まとめ

CloudWatch Agent の procstat プラグインでのプロセス監視できるよう設定を行いました.設定は簡単にできたので別サーバーへの横展開していく時にも活用していきたいと思います.

元記事

元記事はこちらです.

JAWS-UG 朝会 #15 で『AWS Organizations と一緒にはじめるアカウント分離』の取り組みを発表した

みなさん、はじめまして!

スナックミー で SRE を担当している多田です(@tada_infra).スナックミー のエンジニアによるブログが誕生しました! 今後記事で情報発信をしていくのでブログ購読をしてもらえると嬉しいです🙌

スナックミー のエンジニアブログ1発目としてこの記事では 11/18 にJAWS-UG 朝会 #15 にて「AWS Organizations と一緒にはじめるアカウント分離」と題して登壇させていただいたので,登壇資料と登壇を振り返っていきます.

jawsug-asa.connpass.com

登壇資料

登壇資料はこちらです.

今回の登壇の振り返り

今回の発表では現在取り組んでいるアカウントを用途ごとに分離していく活動の模様を発表させてもらいました.入社してからアカウントが1つしかない状況を見て感じた課題からアカウントを用途ごとに分離していっており,アカウント分離にあたっては Landing Zone の考え方を参考にさせてもらって AWS Organizations でアカウント管理をしはじめています.

aws.amazon.com

AWS Organizations と AWS SSO を組み合わせた形でログインしてもらうこともこれまでは直ログインになっているところから変更していきたいですし,他の業務で使っているアプリケーションも AWS SSO と連携できるところも良いなと思っており,社内全体で使えるようにしていきたいと考えてます.今後のアカウントを増やしていく時も引き続き Landing Zone の考え方を参考に分離しつつ,ガードレール機能も設定していきます.

まとめ

AWS Organizations を使ってアカウント分離をしはじめた話を発表させてもらいました.AWS の活用を今後も広げていくとアカウントの数も増えてくるので,AWS Organizations を軸に管理手法とルール作りをやっていきたいと思います.JAWS-UG に参加するのが久々でしたが現場感のある話を聞けて楽しかったですし,また機会作って参加しきます😌

他の方の勉強会参加記事

omuron.hateblo.jp

元記事

元記事はこちらです.