これは「弁護士ドットコム Advent Calendar 2020」の 8 日目の記事です。
昨日は@shotanueのドラッグ可能な複数のポップアップウィンドウをPortalVue(Teleport)で制御する話でした。
はじめに
本記事は弁護士ドットコムにおける分析基盤に秩序を取り戻すまでに行なったことを記したものです。
同じような境遇の方の参考になれば幸いです。
弁護士ドットコムでは各種サービスを展開しておりますが、歴史的な経緯があり、所謂分析基盤はあったものの、混沌としており全てを理解している人はいませんでした。分析用のデータを最終的に格納すべきDBは存在していたものの、その経路がサービスごとに大きく異なっており、DBもマネージドサービスに乗っているものではありませんでした。
1. 可視化
まず手をつけたのは現状の可視化です。
サービス間で知識が分断されており、全体としてどのような経路を通ってデータが流れているのか把握する必要がありました。
各種コードや設定から、どこのサーバー、サービスのどのプロセスがどこにデータを送っているのかを読み解き、以下を作図しました。
各種サービス用のDBからコピーを作成し、複雑な経路を経てマスキングしつつ分析用DBに格納するという流れです。社内事情によりぼかしを入れていますが、ともかく複雑であることをご理解頂ければ幸いです。
2. 問題点の洗い出し
現状が明らかになったところで、図をベースに問題点を洗い出しました。
- 分析用EC2インスタンスが何でもやりすぎている
- redash(BIツール)をホスティングしている
- redashのデータソースとなるDB(MySQL on EC2)を含んでいる
- マスキング処理を行なっている
- にも関わらずあまりメンテされていない
- データの経路が複雑でどこかでコケても検知できない可能性がある
- BIツール用のDBが分散している(MySQL on EC2とGCPのBigQuery)
とはいえ現状の分析基盤は既に各部署で使い込まれていました。redashには多くのダッシュボードが誕生しており、不安定ながらもその役割は大きなものとなっていたのでした。従い、まずは対症療法的に修正可能な部分に手をつけていき、安定化を図る方針を立てました。
3. 基盤の安定化
3.1 対処した問題
3.1.1 redash
安定化の名目で分析用EC2インスタンスでホスティングしているredashをマネージドサービスに逃すことを考えました。社内の多数の部署で活用されているにも関わらず、時たまメモリ不足で動作しなくなってしまったり、アップデートに追従できていなかったりと、分析用EC2インスタンスでホスティングしているが故の問題は数多くあったのです。
その際に行なったことはこちらの記事にまとめていますが、結果としてredashはECSでホスティングすることとし、アップデートにも追従することができました。
redashのメタデータ用のPostgreSQLも同インスタンスでホスティングされていた為、RDSに逃しています。
3.1.2 MySQL on EC2の脱却
redashのデータソースのひとつとなっていたMySQL on EC2もRDSに逃すこととしました。
元の仕組みでは、サービス用のDBのコピーを取っているわけですが、実際にはmysql dumpコマンドを活用し、作成したファイルからのリストアを当該インスタンスの中のDBに対して定期的に行なっていました。
一方、当社のサービス用DBはAurora MySQLを採用しており、こちらも定期的にスナップショットが取得されていました。
今回はこのスナップショットを利用し、分析用RDSインスタンスを作成・削除する仕組みをCodeBuildで作成し、定期実行させることにしました。
しかしCodeBuidはなんでもできてしまいますね。Buildとは。。。
3.1.3 マスキング処理
分析用EC2インスタンスの他の仕事に分析用DBのマスキング処理がありました。社内ユーザーにデータを公開する上で必要な処理ではあるものの、同インスタンスの中で実施されていた為、負荷増大の一因となっていました。
そこでかねてより社内で検討されていたデータベースプロキシの採用を考えました。比較検討の結果採用したのはこちらの記事でも紹介しているDataSunriseという製品です。これは見かけ上DBとしてふるまい、各種ツール(redash等)はDataSunriseをDBとして認識しクエリを発行することができます。DataSunrise側では事前にマスキング設定を仕込んでおき、特定のDBの特定のテーブル、カラムにクエリが発行された場合、そのカラムに事前設定したマスキングを施した状態で結果を返すという仕組みです。
3.1.4 分析用EC2のメンテナンス
同EC2インスタンスがメンテナンスされていない問題については、そもそも今後同インスタンスを破棄する方針とすることから着手しませんでした。
3.1.5 データの経路
3.1.2でMySQLをRDSに逃したこと、3.1.3でマスキング処理をDataSunriseに乗せたことによって必要最低限の経路となりました。
3.1.6 BIツール用DBの分散
社内での使い込まれ具合、特にAWSに乗っていない外部のサービスのデータをBigQueryに多く投入している事情もあり、BigQueryの利用や転送はすぐに停止・変更等できず未着手となってしまいました。
3.2 安定化後の基盤
以下は3.1.1-3.1.3後の基盤の状況です。
BigQueryにデータを転送する部分は未解決ですが、それ以外の部分は当初からするとかなり簡潔にまとまったものとなりました。
各種マネージドサービスに乗せたことでより安定するようになったと言えます。
4. 今後の方針
ひとまず安定化した基盤ですが、データを利用する側からするとまだまだ使いにくい部分が残ってしまっています。
サービス用DBのコピー群がAWSにいて、それとは別にBigQueryが存在するあたりがそれです。
以下は現在検討中の構成の一つで、RDSのデータ、外部サービスのデータ共にBigQueryに直接インポートしてしまうことを考えています。BigQueryの中はデータレイク、データウェアハウス、データマートといった階層構造を取ります。こうして今後は外部サービスを含めた全てのデータをBigQueryに寄せ、データ分析者がより利用しやすい環境を整えようとしています。
一方、直接BigQueryにインポートできないデータはGCSを介するなど、これ以外の設計、マネージドサービス等も検討中です。
まとめ
分析基盤を0から構築する場合と異なり、既に稼働していて多数の利用者がいるものを崩壊させないようにしつつ改良を加えていったあたりに面白味を感じました。現在は多くの技術的負債を片付けつつあるので、今後は本来分析基盤で考慮すべき、ユースケースに合わせた基盤設計を心がけていきたいと思います。