【Unit1 ブログリレー4日目】こんにちは、Unit1（製薬企業向けプラットフォームチーム）の高澤です。ブログリレー3日目は河野さんによる「AWS ECSの各クラスタのデプロイの失敗を横断的に検知する方法」でした。
Unit1 では Web講演会 という医師に向けた情報の講演会ライブ配信サービスを開発・運用しています。2020年から段階的にオンプレからクラウドへの移行を進めており、この記事ではデータベースのクラウド移行と併せて本番データの正当性を担保する仕組みを構築した話をご紹介したいと思います。
背景
エムスリーではサービスのクラウド化を進めています。チーム横断のSREである「コアSRE」が運用するオンプレ環境から、各サービスチーム内のSREである「チームSRE」が管理するクラウド環境に移行すると同時に、権限の移譲やDevOpsの推進などを目的としています。詳しくは以下の記事もご覧ください。
Web講演会サービスも、当初はコアSREが運用するオンプレ環境で稼働していました。しかし、コロナ禍を経ての需要増加に合わせてスケールアップ/スケールアウトで対応する必要が出てきたこともあり、段階的にクラウド化を進めていくことになりました。従来のサービスで提供していた機能の移行に加えて、今回新たに取り組んだのが本番データの正当性を担保する仕組みづくりです。
Web講演会サービスではサービス特性上、各講演の告知、予約、視聴の実績データをデータベースに記録しています。これらの記録は会員の方がマイページから確認できる記録という側面もありますが、サービス改善などでも活用されるビジネス上でも重要なデータになります。
今まで利用してきたオンプレ環境では、コアSREが一括で管理しているデータ管理の仕組みに相乗りする形で対応できていましたが、クラウド化後はコアSREの手を離れてチームSREが個別に対応することになります。
実現したいこと
オンプレ環境でのデータ管理の仕組みに習い、チーム内で検討してクラウド化後のデータベースでも以下の2点を整備すべきではないかと考えました。
- 本番データが改ざんされない、もしくは改ざんされても検知できる仕組みを整備すること
- データ修正が必要な場合は、それが正規のプロセスで承認を得た変更であることを後から確認可能であること
1.については、データがそもそも正しく記録されているか？のチェックになります。基本的に本番データはサービスのロジックに従って記録されるべきであり、それ以外の変更がないことが保証されている必要があります。対して、2.については何かしらのトラブル対応時を想定しており、データ修正が必要となってしまった場合に正当な手順で実施されているか？のチェックになります。
一方で、サービスの開発者やチームSREとしては「現在の開発体制やフローをできるだけ変更したくない」「新しく追加する管理の仕組みはできるだけ少なくしたい」という希望があります。
これまでもデプロイやデータ修正の記録はワークフローで管理していましたが、これに追加となる形で管理の手間を増やしてしまったり、開発者の権限を必要以上に制限する方向で対応すると、開発スピードの低下につながり迅速なリリースの妨げとなってしまいます。また、新しく複雑な仕組みを導入することは、今後の運用コストを考えるとできるだけ避けたいことでもあります。
方針検討
今までの管理方法はできるだけそのまま維持した上で、できるだけ負荷が少ない方法での仕組みの整備を目指し、以下のような対応方針を立てました。
- 緊急時のシステムメンテナンスなどに備え、本番DBの更新権限を開発者にも付与しておく（従来通り）
- DB変更を行う際は、ワークフローを起票して作業内容について一定の承認を得た上で、権限を持った管理者が作業を実施する（従来通り）
- 本番データの変更については、以下の仕様でログを残す（新規に追加）
- ログの項目として、変更した日時・実施ユーザー・変更内容を含める
- 開発者には参照権限のみ付与し、改ざんできない状態を維持する
- 少なくとも1年間はログを保存する
新規に整備する仕組みはログの保存にとどめることで、従来の開発体制やフローには影響を与えないようにし、管理コストの増加を抑えるようにしました。また、変更内容の詳細をログに残しておくことで、万が一変更があった場合にもそれが恣意的でないことを後から確認できるようにすることを意図しています。
実装
データベースは AWS の Aurora PostgreSQL を利用していたため、拡張機能 pgaudit を利用してログを残す仕組みを構築しました。
具体的には、本番データを変更する SQL を実行した場合、pgaudit を使って CloudWatch に流すログに出力するようにします。そのうち、サービスのロジックからの更新ではない、管理者ユーザによって実行されたものだけをフィルタリングし、 Kinesis を通して S3 にログファイルの形式で格納します。 S3 への書き込み権限はログを記録する CloudWatch からのみに絞り、その他のユーザには参照のみの権限を与えることでログファイルが変更されることを防ぎます。S3 バケット自体への変更についても CloudTrail で記録するようにし、大元からの改ざんも防ぐようにしました。
また、ログファイルが追加された場合、内容を Slack に通知するような Lambda も合わせて追加しました。 Slack への通知にも DB 変更の日時・実施者・変更内容を一通り載せるようにしました。通知が来た場合はチーム内の定例会議で確認することで、データの変更が恣意的に実施されていないことを担保しています。
効果とこれから
上述の仕組みは従来の開発およびリリースのフローに影響を与えない形で導入したため、開発チームには導入前の説明と導入完了の報告のみで、その他は今までと変わらずに開発およびリリースを進めることができています。運用面でも、基本的には AWS 上で利用可能なサービスを組み合わせているため、チームSREとしても大きな負荷を感じることなく運用ができています。
この仕組みは今後のサービスのクラウド化でも横展開可能かと思いますので、できるだけ開発者およびチームSREへの負担が少ない形で整備が進められればと考えています。
We are Hiring!
エムスリーではサービスの開発・運用を通して、技術を使った課題解決に興味のある方を募集しています。 少しでもご興味のある方は、ぜひ下記リンクからカジュアル面談等にお申し込みください。
