Managerを使ったServerlessの構築をします。Managerを使ったアーキテクチャ図こんにちは。Stageになったことが報告されました。居ても立ってもいられず、自分のプロダクトのDev版に実装し、検証をしました。このプロダクトはServerless界隈では強く求められていたのではないかなと思っています。Managerを使った構築例を紹介しようと思います。asia-northeastがないのが残念な点で、プロダクションに使うことを検討している方はしばらく辛抱が必要です。運用という観点にも注目したいと思っています。ManagerのアイコンServerlessで求められていた理由Serverlessのデメリットとして「コールドスタート」が有名なのではないかと思っています。ゼロスケールをするからこそ、逆に言うと「ゼロから作る必要がある」ということです。そもそもServerlessは起動が遅く、同期的なアプリケーションには適していません。イベント数に対してインスタンスはスケールをして、線形な課金がされるようなServerlessの理想の姿にできる可能性があります。ユースケースに応じてServerlessが有用であり、実際に私自身もServerlessで比較的、低コストでサービスを運用しています。ManagerがServerlessで求められている理由を知るには以下の点を留意・注意する必要があります。Secretは環境変数ではないこれは当たり前ですが、Serverlessプロダクトとの相性が悪い概念なので常に注意する必要があります。Serverlessと特徴として「ビジネスロジックに集中できる」がよく取り上げられますが、Securtity的な保証は自分がしなければなりません。データベースへ接続するServerlessアプリケーションがあったとしましょう。この場合、以下のものが大抵の場合は必要ですがSecretと環境変数に分けることができます。漏洩してはいけないものなのです。漏洩しても影響がない形にしなければなりません。Runではデプロイ時に以下のように環境変数を渡すことができます。Functionsではデプロイ時に以下のようにファイルを指定します。Runのように--set-env-varsと指定して渡すこともできます。Securityを犠牲にしてEnvと同じ用にSecretも関数へ渡しているケースをよく見かけます。Stringで見ることができてしまいます。Secretを実装したとします。Secretはアプリケーション内で復号化してSecretをさします。RunなどのSLOが99.9%だったとします。Secretの復号化なのに使っているServerlessのSLOをかなり下回るプロダクトができてしまうこともあります。KMSはレイテンシが大きく、Serverlessのようなイベント駆動型のアプリケーションで使うことを想定していません。Secretをインスタンス起動時に復号化するというアプリケーションの方が適しています。Secretがうまく行かず、アプリケーションで復号化をするようなアプローチを取れなかった背景があります。Managerが登場しました。用語を先に抑えるとドキュメントが読みやすくなります。バージョンごとの実際のデータ。5など指定するときとlatestがある。Versionを一意に特定するためのパス。VersionにどんどんSecretを格納することになります。Versionはシーケンシャルに番号が振られます。アプリケーションからSecretを生成することよりも読み取ることの方が多いと思うので以下にサンプルを載せておきます。Nameぐらいになります。それは漏洩してもリソースへのアクセス権限がなければSecretを取得することはできないため安全です。アーキテクチャアーキテクチャはシンプルです。Functionsからアクセスをすればよいです。Managerが使えるのかどうかを見たいと思います。以下のような料金体系になっています。料金を抑えるためにはリージョン数を絞るのは現実的かもしれません。クオータここが大きな注意点です。以下のようなクオータが設定されています。プロジェクトにつき毎分600書き込みについては毎分600回を超えることはないと思いますが、大規模なアプリケーションで使用する場合アクセスリクエストはアプリケーションに対して注意深く見る必要があると思います。ManagerのためのRoleとして以下のようなものがあります。Secretを取得するだけにはroles/secretmanager.secretAccessorで十分です。Secretとしてアップロードをして、CI内のジョブとしてSecretをアップロードする必要性があると思います。Secretを管理するためのCIそしてアプリケーションからアクセスをする仕組みづくりが必要なのではないかなと思っています。SecretなのでTerraform管理をするわけにもいかないし、なにか策がほしいものです...Secretの内容Secretは単純なStringではなく、ファイルとしてアップロードできます。JSONでもYAMLでも、どんなファイルでもSecretとしてプログラムからアクセスができるためアプリケーションに合わせて柔軟に使っていくことができます。UI上で権限があると中身を見ることもできるので、権限管理には注意が必要です。KMSほどではありませんがローカル環境からAPIを叩いても約1秒程度レイテンシが毎回発生していました。KMSは5秒などかかっていたこともあった)のでいいとしましょう。Serverlessの場合も一般的なServerと同様に実行時間によって課金されるので注意してください。Managerが登場して、ServerlessプロダクトでのSecret管理が非常に楽になりました。UI上でSecretが露出してしまうことがなくなり、より安全に運用できていると思います。どのようにして継続的に管理をしていくか考える必要があります。現状はGithubでの復号化して、それをアップロードするというSecretをアップロードステップと、プロダクトのデプロイステップの2つのステップがあります。Manager用のアップロードツールを作ろうと思っています。Managerのようなものが出てくるおかげでSecretの管理もし易くすむのでよりServerlessのメリットがより活かせそうだなと感じました。最後までありがとうございました。KeisukeYamashita。