SKYPCEでは、既存機能についてもCI/CDの推進や最適化を通して、ブラッシュアップを行っています。
SKYPCEのVer4.2では、従来はEC2インスタンスの定期実行で行っていた処理の一部をAWS Lambdaに移管するような変更を加えました。
この変更に伴い、LambdaからAmazon RDS (Relational Database Service) にアクセスする必要が出てきました。
RDSにアクセスするには当然、接続するための情報が必要になります。
従来構成では、EC2インスタンスが起動時に接続情報を取得できれば問題なかったため、RDSへの接続情報はParameter Storeに保管されています。
普通に考えれば、LambdaからParameter Storeにアクセスして取ってこればよさそうです。
一口メモ
MySQLやPostgreSQLであればIAMによる認証も可能でしたが、
使用しているDBはRDS for SQL Serverなため、この手段は取れませんでした。
※RDS Proxyを使えばIAM認証も可能ですが、費用面やユースケース等を鑑みて却下しました。
一口メモ
接続情報の保管場所を別にすることも考えましたが
そこまでうま味も感じなかったため、既存構成を生かすことにしました。
しかし、Parameter Storeではクォータ毎にアクセス上限が設定されていて、短い期間に高頻度でアクセスするとスロットリングが起こる可能性があります
※スロットリング：システムの過負荷を防ぐため、一定の時間処理を制限すること
要するに、Parameter Storeは、"頻繁にアクセスするようなシーケンスには向いていない"ということになります。
今回は複数のLambdaから同時にアクセスする必要があったので、尚のこと不適切です。
ということで、以下のようなアプローチで打開策を考えてみました。
考えたアプローチ
アプローチはいくつかあると思いますが、パッと思いつくのは以下のような方法でしょうか
- 案1：Parameter Storeのサービスクォータを増加する(上限を引き上げる)
- 案2：Lambdaの環境変数にParameter Storeの値をセットしてしまう
- 案3：何等かの方法で接続情報をキャッシュする
案1はまず無いでしょう。
引き上げることもできなくはないですが、「ここまで引き上げればOK」という目安が難しいですし、そもそも、そういう用途で作られていないリソースに対して上限を引き上げてなんとかしよう、というのはナンセンスだと思います。
案2はパッと見た感じ、いい案に思えます
しかし、今回保持したい内容はDBへの接続情報で、秘匿性が高い内容。
環境変数に設定してしまうと、その情報がほぼ丸裸な状態になってしまうため、セキュアでない。
採用するのはなかなかリスキーです。
ということで、案3のキャッシュを選択することにしました。
キャッシュする方法
キャッシュを使うにあたっては色々な方法があります
例えば、ElastiCacheを使うといったことも考えられますが、今回はお手軽にできるglobal変数を使うことにしました。
方法は簡単で、以下のようにglobal変数を定義してセットするだけです。
※実装例はPythonです。
global_var = None
def lambda_handler(event, context):
global global_var
if global_var is None:
print('グローバル変数に値をセット')
global_var="ほげほげ"
print(global_var)
キャッシュを使いたいところでglobalで宣言し、使うだけ！
実際に動かしてみると、以下のようにログが出ていました。
timestampmessage2025-10-14T14:48:37.846+09:00グローバル変数に値をセット2025-10-14T14:48:37.963+09:00ほげほげ2025-10-14T14:48:41.216+09:00ほげほげ
「グローバル変数に値をセット」というログが1度しか出ていないことから確認できるように、キャッシュを使うことができているようです。
実際のコードでは、取得部分ではParameter Storeからデータを取っていますが、これで、いい感じにアクセスを減らすことができました
キャッシュを使う際の注意点
もちろん、注意すべきこともあります。
今回のParameter Storeの値は滅多なことで更新されない値であるためキャッシュを使うことが成立していますが、例えば頻繁に更新がされるようなものであれば今回の使い方は不適といえるでしょう。
(Parameter Storeでそういう使い方をすることはまずないと思いますが・・)
仮に、上記のような場合に使用する場合にはLambdaが同時に実行された場合を考慮して一貫性を保つ工夫が必要と言えます。
それから、キャッシュが保持される期間はLambdaがウォームスタートできる期間です。
Lambdaの実行に関する動作は コチラ を参照してください
逆にいうと、ウォームスタートされる期間はキャッシュが揮発せずに残るので、不用意にglobal変数を使ってしまうと、意図しない値が入っている可能性もあります。
便利ではありますが、使い方を誤ると不具合のもとになってしまうのでお気を付けください。
まとめ
今回はLambdaからParameter Storeにアクセスする際のアクセス頻度を減らす方法としてglobal変数を使ったキャッシュを利用する方法をご紹介しました。
ご紹介した方法が必ずしも最適であるわけではありませんし、要件毎/設計毎に最適な方法は異なってくるかと思います。
その場面場面で、最適なアプローチがあると思いますので、都度、柔軟に検討/選択いただくことが重要と考えています。
以上、本記事が少しでも皆様のお役に立てば幸いです。
