How to ensure the consistency of serverless business deployment updates

サーバーレスを専門とするエンジニアとして、サーバーレス環境でのデプロイ更新における一貫性をどのように確保するかという質問に、よく遭遇してきました。

ここで言う一貫性とは、ツールを使ってプロジェクトをローカルにデプロイした後、他の誰かがコンソールなどの別の手段でプロジェクトを更新した場合、ローカルから再デプロイした際にそれらの変更がそのまま上書きされてしまうかどうかという問題です。

たとえば、ユーザー A がローカルで更新作業を行っている際に、何らかの事情によりオンラインで異常「x」が発生したとします。その間にユーザー B が更新を行い、問題を修正しましたが、B は A にその旨をタイムリーに共有していません。その後、A が新機能の更新をデプロイした際に B の修正内容をそのまま上書きしてしまい、先ほどの異常 x が再発してしまいます。もしこの時、A がデプロイする際にオンラインリソースの変更を検知できていれば、こうした事態は防げたはずです。

現在、Serverless Devs ベースの Alibaba Cloud Function Compute コンポーネントは、オンラインの「異常な変更」を検知できるようになっており、以下のシナリオに対応しています。

1. ローカルで新規リソースを作成してデプロイする（オンラインに該当リソースなし）

2. ローカルデプロイ完了後、オンラインで更新が行われ、ローカルで再デプロイする

3. ローカルでオンライン既存のリソースを作成してデプロイする

実験の準備

init コマンドで関数を作成します（Alibaba Cloud Serverless を選択し、HTTP 関数 - Python 3 テンプレートを選択）。

ここで s.yaml の内容を確認します。

プロジェクトをデプロイすると、中国（杭州）リージョンに FC デプロイサービスと HTTP トリガー関数が作成されます。

ローカルで新規リソースを作成してデプロイする（オンラインに該当リソースなし）

この時点ではオンラインに対応するリソースが存在しないことを確認済みのため、次のようにデプロイを実行します。

デプロイは正常に完了しました。

ブラウザを開き、提供されたカスタムアドレスを確認します。

次に、ローカルで関数コードを更新します。

保存してデプロイを実行します。

完了後、オンラインリソースを再度確認します。

一連の流れは従来の基本的なプロセスとほぼ同じで、オンライン側の変更は一切検知されませんでした。これは理想的な正常系のプロセスです。

ローカルデプロイ完了後、オンラインで更新が行われ、ローカルで再デプロイする

ここでは、コンソールでオンラインリソースに変更を加えます。まず、コンソールで対象の関数を見つけます。

コードを変更してデプロイします。

デプロイ完了後、先ほどのアドレスをリフレッシュします。

更新されていることが確認できます。次に、ローカルからデプロイを実行します。

ご覧の通り、システムがコードの変更を検知しました。ここで yes を選択し、完了後にオンラインリソースを確認します。

重要な点として、Function Compute のサービス、関数、トリガーのいずれに変更があれば、設定の変更でもコードの変更でも、ここで検知されます。

ローカルでオンライン既存のリソースを作成してデプロイする

最後に、ローカルプロジェクトを削除して再作成し、デプロイを実行します。先ほどの実験の結果、オンラインには既にこれらのリソースが存在するため、今回の操作はオンライン既存リソースへのデプロイとみなされます。

ご覧の通り、システムはローカルで未デプロイだがオンラインに既存のリソースを検知し、上書きするかどうかを確認してきます。

まとめ

他のシナリオでのコード更新についても、システムが変更を検知できることが重要です。これはコードの安全なリリースに直結する重要なポイントであり、Serverless Devs で実現できます。

では、既存のプロジェクトを CD プロセスに統合したいが、インタラクティブな操作を避けたい場合はどうすればよいでしょうか。

`--use-local` パラメーターを使用して、オンライン設定を強制的に上書きできます。このパラメーターにより、非インタラクティブなローカル優先のデプロイが実現します。

すべてのツールには成長のプロセスがあり、Serverless Devs も発展を続けています。今後もさらに優れた機能が追加されることを期待しています。