はじめに
こんにちは。サイカでソフトウェアエンジニアをやっているshohhei1126です。前回の記事ではサイカにとってのオブザーバビリティとはについてシェアさせていただきましたが、今回は少し毛色の違う弊社の分析環境についてお話させていただこうと思います。
サイカではMagellanを使った分析の他に、お客様のご要望に合わせたアドホックな分析やデータサイエンティストが研究目的で行う分析などがあります。
そういった分析を行う際、もちろん各作業者のマシンに分析ツールをインストールし作業を行うこともできますが以下のような問題が発生します。
- CPUアーキテクチャやOS、ソフトウェアのバージョンなどを統一しにくく、一貫性のある分析結果を出すことが難しい
- 分析実行中は作業者マシンのCPUやMemoryなどのコンピュータリソースを消費してしまうため、その他の作業の効率が落ちる
- 個人情報を含むデータを使って分析する際に作業者マシンにダウンロードせざるを得ない
そこで弊社ではオープンソースの JupyterHub と JupyterLab をベースにサイカ独自の拡張を加えた共通分析環境を運用しています。
この記事ではその共通分析環境で提供している機能を網羅し紹介することにします。（個々の詳細については今後別の記事で触れる予定です）
アーキテクチャの外観
それぞれの分析者に専用のJupyterLabを提供するためのツールとしてJupyterHubというものがあります。
(https://jupyterhub.readthedocs.io/から引用)
JupyterHubにはユーザの要求に合わせてJupyterLabを生成・管理する機能（Spawner）、OAuthなどの認証機能、独自に機能拡張するための使用可能なAPIなどがあります。
Spawnerはインターフェースとなっておりそれぞれの実行環境向けに実装されたものが用意されています。サイカでは柔軟なインフラリソースの管理ができるKubeSpawnerを使用しEKS上に構築しています。
また、サイカでは全社的にGoogle Workspaceを利用しているためJupyterHubの認証にはGoogleによるOAuthを使用しています。そのため全社員が利用するとこができます。
JupyterHubのAPIに関しては案件ごとに権限管理する必要があるためそのAPIを利用して機能拡張も行っています（後述します）。
拡張した機能たち
前述の通りJupyterHubは抽象化されたインタフェースを提供しており、ユースケースに合わせて拡張ができるようになっています。ここではサイカ独自に拡張した主な機能をご紹介します。
Google GroupによるJupyterLabの起動制限
データサイエンティストやアナリストの要望でハイスペックなJupyterLabを起動できるように準備していますが、前述の通り全社員がこの共通分析環境を利用できるため意図せずインフラコストが上がる可能性があります。そのためGoogle Groupを利用しデータサイエンティストやアナリストのみハイスペックマシンを起動できるような制限を追加しています。
実装方法はKubSpanwerクラスを継承する形でバリデーション処理を追加しています。
JupyterLab内で起動したアプリケーションへの認証付きHTTPアクセス
JupyterLab上で簡易的な分析ツールを作成し他の社員へ共有したい場合があります。そのためKubernetesのIngressとAWSのCognitoを利用し認証付きの公開URLを動的に生成しています。
JupyterHubのServiceを使った案件管理
前述の通りJupyterHubにはAPIがありそれを使って任意の拡張をすることができます。それに加えてServiceという機能もありJupyterHubをOAuthプロバイダーとしても利用することができます。
これによりJupyterHubにログインしているユーザのアクセストークンを取得することができるため、そのユーザに合わせた機能（例えば権限のある案件だけ一覧に表示するなど）を実装することができます。これについては別の記事で詳細にふれる予定です。
Amazon EFSの利用
インフラとしてAmazon EKSを使用してる（Podが消えるとデータも消える）ため、JupyterLab上で作成したデータをどのように永続化するか検討する必要があります。
EFSとFSx for Lustreを検討しましたが当時運用していたEKSのバージョンでは後者が対応されていなかった点と前者のほうが実績があると判断したためEFSを採用しました。
ユースケースとしてはユーザごとのホームディレクトリと案件ごとのデータなどの永続化に使用しています。
その他非機能的な話
最後に運用する上で必要な非機能的な話にも触れておきたいと思います。
Datadogによるモニタリング
JupyterLabが起動中であれば以下のようなのactivityログを定期的にJupyterHubに送信するようになっています。
[I 2024-11-11 16:38:10.838 JupyterHub log:192] 200 POST /hub/api/users/{ユーザID}/activity ({ユーザID}@xx.xxx.x.xxx) 7.38ms
ログの中にタイムスタンプとユーザIDが含まれるためこれを元にDatadogで可視化しダッシュボードを作りました。これによりどのように使用されているかを把握するができるようになっています。
ポータルサイトの作成
共通分析環境を運用する中で「ここの仕様どうなってますか？」といったお問い合わせが増えてきたため全社員が参照できるポータルサイトも作成しました。
サイカ社内のドキュメンテーションツールとしてNotePMが使われていますが、ポータルサイトの品質を維持するためにレビューのしやすさ（エンジニアが慣れたプルリクエストベースのレビュー）を重視しGitHubで管理することにしました。内容はMarkdownで記述してHugoでサイトを生成しています。
さいごに
今回は共通分析環境について概要レベルですが全体的にシェアさせていただきました。
今後は別の記事でそれぞれの詳細に触れていく予定ですので、ぜひそちらも読んでいただけると幸いです。
