はじめに
Parameter StoreはAWSのサービス間でパラメータの受け渡しを行う際に、非常に便利なサービスです。
似たようなサービスとしてAWS Secrets Managerも存在しており、よく使い分けについての記事も書かれたりしていますが、今回は私がParameter Storeを利用する上で便利だと感じていること、こうしたほうがいいと思っていることをまとめたいと思います。
1. パラメータ名について
パラメータ名は自由に作成できますが、私がパラメータ名として登録する場合は以下のような階層構造にすることが多いです。(場合によってはサービス名の上位概念として会社名を入れることもあります。)
/{ServiceName}/{EnvName}/{AWSServiceName or OtherServiceName}/id
昔関わったサービスで hogehoge-id のようなパラメータ名で登録しているケースを見たりもしました。
1つのサービスしかなかったり、環境毎にAWSアカウントをきっちりと分けている場合はそれでも問題ないですが、スタートアップのサービス立ち上げ当初などはAWSアカウント1つで管理されている場合も多く、パラメータ名を共通にしておくと事故が発生しやすいです。(その後、環境毎にアカウントを分離する際にも、パラメータ名にサービス名と環境名を含むと分離しやすいです。)
階層構造にする場合のメリット
公式ドキュメントにも記載がありますが、以下2点メリットがあります。
- 階層内のパラメータを一括で取得できる
- IAMポリシーで階層に対してのアクセス許可が可能になる
これらを活用することで、先の1アカウントで複数環境を運用する場合でも、適切な権限管理がしやすくなります。
2. ラベルについて
各パラメータは履歴管理されており、履歴に対して自由にラベルを付与できることはご存じでしょうか。
以下はあるパラメータの履歴タブのスクリーンショットです。
パラメータの値を更新するたびにバージョンが振られ、そのバージョンごとに重複のないようにラベルをつけることができます。
ラベルをつけると何が便利になるか。
例えば、上記ではDockerイメージのtagを管理していますが、本番環境に最新で適用しているtagに Current ラベル、1回前に適用していたtagに Fallback ラベルを付与しています。
もし本番環境で問題が発生した時、環境を適用前の状態に戻すため利用しています。
コンテナ化する前はAMIを作成してEC2インスタンスを起動するような構成にしていましたが、その場合でもAMI IDを管理して同じようなことを実現していました。
ちょっと古い記事にはなりますが、こちらの記事を参考にしています。
EventBridgeとの連携
EventBridgeのルールを利用し、該当パラメータの更新イベントをトリガーに、サービスをデプロイするためのCodeBuildなどをターゲットとすることで、パラメータをハブとしてCI/CDのパイプラインを作成することができます。
以下は実際に利用しているフローの一部を抜粋したものになりますが、CodePipelineでフローを組むよりも取り回しがしやすいと感じています。
※注意点として、Parameter StoreをイベントソースとしてEventBridgeを利用する場合、Systems Managerの試行タイプがベストエフォートとなっているため、イベントが発火しない場合があります。
例えばslackに通知するなどして、発火しなかったことに気付けるような設計にするなどの工夫は必要になります。
さいごに
個人的な見解も含んでいますが、Parameter Storeはとても便利なサービスだと思っています。
今年2月のアップデートでクロスアカウント共有もサポートされ、ますます便利になりそうです。(Advancedのみなので、お金かかります)