データ共通BITA部の玉井 孝平です。
2021年2月のtechtektのインタビュー記事、法人顧客に向き合うすべての社員をサポート！―BIツールの導入・普及のウラガワにて、パーソルキャリアにおけるPower BI活用事例についてご紹介いただきました。
我々データ共通BITAでは、分析、可視化業務担当者に合ったツールを提供すべくTableau、Power BIを中心とした環境を提供しています。今年度、Power BIの実行環境のリニューアルを行ってきました。呼び難いため以降、BI（ビーアイ）システムとします。今回はそのアーキテクチャに着目して紹介します。
BIシステムとは
BIシステムをリリースしたのは2017年下期に遡ります。現在のBIシステムと区別するため、旧世代BIシステムとでもしておきます。
世の中に目を向けると、当時のBI界隈はセルフサービスBIって話題がどこに行っても飽きるくらいに言われていました。BIと言うテーマ自体は古くからある、使い古されたものでしたが、昨今のデータ活用に対する企業のプライオリティの変化やBIツール自体がユーザーライクに変化したことなどを背景にして、一気にBIツールが非エンジニア層にまで広がって行きました。
そんな流れを受けて、パーソルキャリアにおいても転職メディア事業部の分析担当者向け環境構築が行われました。システム構成としてはすごくシンプル。AWS環境にEC2とRedshiftを新規構築。
Redshiftには、我々データ共通BITAが以前より管理している分析基盤(AWS)に蓄積している基幹システムから連携してきたテーブルを元に集計、加工したテーブルをデータマートとして連携しています。
Power BIを利用するためにはWindows OSの環境が必要です。ただし、会社支給PCからデータベースへのアクセスがレギュレーションでNGとなっているため、EC2を別途用意してPower BI Desktopをインストール。分析担当者が会社支給PCからRDP接続して環境を利用する構成としていました。
旧世代BIシステムの課題
リリース後、業務連携部署の協力もあって、利用範囲を拡大して行きました。
そして2020年度、転職メディア事業部用のEC2をスケールアウトさせた形で、事業縦割りのEC2が複数できていました。
この事業部縦割りの構成が旧世代BIシステムの欠点、とにかく運用コストが掛かっていました。
新しい事業部でPower BIを利用したいとなると、EC2を増やさないといけない。利用者が拡大したら、EC2のスケールアップが必要だし、RDP接続の同時接続を許可するためのWindows CALも必要になります。一方では利用者が伸び悩んだ事業部もあり、その場合は環境の統廃合が発生していました。
アカウント管理をそれぞれEC2のローカルユーザー管理にしていたことも運用負荷を上げる一因になっていました。データ共通BITAが管理するWindows OSのサーバーは他にも存在して、人によってはアカウントを複数管理してもらっていました。部署異動発生時のアカウントの付け替えも手間になります。
障害対策もまた然りです。EC2は各事業で1台のみの構成のため、障害が発生すると業務を停止してもらっていました。若葉マークの分析者が大量テーブルの複数結合など行った場合、リソース枯渇が発生して、他の分析者の操作が応答不能になることなどもしばしば。
この状況を改善すべく、2020年12月、データ共通BITA部シニアエンジニアの鈴木裕之氏の企画を元にしたBIシステム刷新に着手しました。
新BIシステムβ版アーキテクチャ
新BIシステムのβ版の構成図はこちらです。クラウドサービスは引き続きAWSを利用。
使用したAWSのサービスは以下となります。
- Directory Service(MicrosoftAD)
- EC2
- Elastic Load Balancing(Classic Load Balancer)
- FSx(Amazon FSx for Windows File Server)
- Redshift
システム刷新のポイントは3つです。
Point１．コスト削減
Point２．冗長構成
Point３．負荷分散
Point１．コスト削減
運用コスト、ソフトウェアのコストにも無駄がありました。せっかく無償のBIツールであるPower BI Desktopを使っているのでツール以外のコストも下げたいことが1つ目のポイントです。
- アカウントの統合
AWS Directory Service(Microsoft AD)を使ってアカウントを統合。データ共通BITAが提供する他システムのアカウントと共有できるようにしました。分析担当者にとってはアカウントの二重管理の解消、我々データ共通BITAとしてもメンテナンス工数の削減ができました。
- Windows CALの統合
Windows CALライセンスサーバーにCALの一元管理を委ねて、各EC2はライセンスサーバーを参照する構成にしました。こちらもメンテナンスコスト、不要なライセンス購入の削減につながります。
Point２．冗長構成
分析担当者の業務が止まらないように冗長構成を取り入れたことがポイントの2つ目です。
利用者からの見え方として、どこに接続しても同じサーバーに接続しているような状況を作りたかったため、インスタンスタイプが同じEC2を5台用意。FSx(Amazon FSx for Windows File Server)をドライブとしてアタッチして、ファイルは必ずFSxに配置してもらうようにすることで同じサーバーに接続しているような状況を作りました。
Point３．負荷分散
ポイントの3つ目は負荷分散です。旧世代BIシステムでは同時接続利用者数にサーバー間で偏りがあったため、利用者数を平準化させたい。そのため、Elastic Load Balancing(Classic Load Balancer)をEC2に接続させて、負荷分散のソリューションとしました。とはいえ、この後課題が発生して別の構成に変更したのと、2022年にはClassic Load Balancerが廃止されるので詳しくは書きません。
β版の課題
Classic Load Balancerの懸念は開発段階からありました。それは負荷分散としての機能がラウンドロビン式である、つまり適当に振り分けられることでした。鈴木氏と、「なんとかうまいことさばいてくれるんじゃないかな」、と面白おかしく話していたことを懐かしく覚えています。課題となるポイントはその他にもありました。セッション情報の管理が弱かったことでした。
リリース後、不安は的中して、次のような問い合わせや管理者検知のインシデントが頻発しました。
|
# |
インシデント |
原因 |
|
1 |
アプリの操作がいつもよりも重たい |
あるEC2に利用者が集中しすぎていたため。ラウンドロビンの振り分けが起因。 |
|
2 |
ネットワーク不調でRDP接続が切断、再度RDP接続したら作業中のウィンドウがなくなった |
再接続時に別のEC2に接続されたため。セッション管理が十分ではないことが起因。 |
|
3 |
ある利用者のセッションが5台のEC2インスタンスすべてに存在した |
RDP切断と接続を繰り返したため。セッション管理が十分ではないことが起因。 |
RD接続ブローカーとは
課題解決のため着目したアーキテクチャが、リモートデスクトップ接続ブローカー(以下、RD接続ブローカー)でした。RD接続ブローカーに管理対象のサーバー(以下、RDセッションホスト)を登録すると、セッション管理をいい感じにしてくれます。特徴として次の機能を有しており、β版の課題を解決の期待を寄せました。
- どのユーザーアカウントがどのセッションホストに接続しているかのセッション情報を管理してくれる
- 接続ユーザーアカウント数を鑑みて、接続数の少ないセッションホストに新規接続を振り分けてくれる
RD接続ブローカーの実装
実装にあたっての調査段階にて、Windows2012 OSをベースとした手順は散見されました。今回我々が構築したOSはWindows2016。RD接続ブローカーのセットアップ手順がOSにより異なっていたため、はまりましたがマイクロソフト社のサポートもあって実装することができました。
せっかくなので、その手順を公開したいと思います。
STEP１．RD接続ブローカーのインストール
RD接続ブローカーをインストールするサーバーにて、Windowsサーバーマネージャーから行います。
サーバーマネージャーを起動して、[③管理するサーバーの追加]。
RD接続ブローカーの管理対象となるRDセッションホストを追加して、[OK]。
前手順にて指定したRDセッションホストが追加されていることを確認します。
[管理]→[役割と機能の追加]。
[次へ]。
[リモートデスクトップサービスのインストール]を選択、[次へ]。
[標準の展開] を選択して、[次へ]。
[セッションベースのデスクトップ展開]を選択、[次へ]。
[次へ]。
インストール作業を実施しているサーバーを選択して[次へ]。
同じく、インストール作業を実施しているサーバーを選択して[次へ]。
RDセッションホストとなるサーバーを選択して、[次へ]。
設定が正しいことを確認して[展開]。
成功が表示されていることを確認して、[閉じる]。ここでOS再起動がベターです。
STEP２．セッションコレクションの作成
STEP1に続いて、サーバーマネージャー →リモートデスクトップサービスを表示します。
画面中央の右下にて[RDセッションホスト]の文言が表示されていて、右クリックメニューの[セッションコレクションの作成]をクリック。
[次へ]。
任意の名前を設定して、[次へ]。
RDセッションホストを選択して、[次へ]をクリック。
RDPを利用するユーザーアカウントが所属するグループを選択して、[次へ]。
[次へ]。
設定が正しいことを確認して、[作成]。
成功となっていることを確認して、[閉じる]。グループポリシーの設定によっては、画面のような警告が出ることがあります。読み飛ばしても良い内容かどうかは確認してください。
STEP３．RD Webからリモートデスクトップファイルのダウンロード
実装は後少しです。
RD接続ブローカーサーバーにHTTPS通信が可能な場所で、Google ChromeまたはMicrosoft Edgeを起動、下記URLを入力します。
https://(RD接続ブローカーサーバーのIP or サーバー名)/RDWeb</ code>
画面下部にある、「(RD接続ブローカーサーバー名)にアクセスする（安全ではありません）」をクリック。
ユーザー名とパスワードを入力して、[サインイン]をクリック。
STEP2で作成したセッションコレクションが表示されます。ダウンロードします。
拡張子がRDPのリモートデスクトップ接続の設定ファイルがダウンロードされます。実行するとRD接続ブローカーを経由して、RDセッションホストに接続できます。
ちなみにこのファイルをテキストエディタで開くことができ、編集も可能になっていますが、編集禁止の設定もあるため触らないことがベターです。
BIシステム再リリース後の状況
現在のBIシステムの構成図はこのようになっています。Classic Load Balancerの代わりにご紹介した手順にて構築したRD接続ブローカーをインストールしたEC2を配置しています。
この構成にして、3ヶ月程度運用してきました。目立った障害もなく、1日あたり50人以上が利用、同時接続30人を可能とするセルフサービスBIを実現するシステムとなっています。
スケールについて
今後の拡張に対しの考慮もしています。利用者が増えた場合にはEC2のスケールアウトを行う、扱うデータ量がシステム全体として増えた場合はEC2インスタンスのスケールアップ行うだけのシンプルなプランです。現状はまだその検討段階に入っていません。
最後に
今回は我々データ共通BITA部にて実行したBIシステムの刷新について、またRD接続ブローカーの実装手順についての文献が乏しいことからその手順をご紹介させていただきました。セルフサービスBIシステムの新規構築を考えている方、または現状課題を抱えてられる方のご参考になれば幸いです。
今回触れられていないポイントも多々あります。Redshiftにどういうデータを連携しているのか、Power BI Gatewayとは何、Power BIパブリッシュ機能ってあるけどどのように使っているのか、等触れていないこともあります。また機会があればご紹介したいと思います。
玉井 孝平 Kohei Tamai
インフラ基盤統括部 データ共通BITA部 リードエンジニア
パッケージソフトベンダーで製品導入支援やシステム開発に従事。2017年に株式会社インテリジェンス（現パーソルキャリア株式会社）に中途入社。データ共通BITA部にてBIツールの利用環境整備やデータ活用支援を担当。
鈴木 裕之 Hiroyuki Suzuki
インフラ基盤統括部 データ共通BITA部 シニアエンジニア
オフも全力で。音楽FES、トラウトルアーフィッシング、アクアリウム、サイクリングなどでリフレッシュしています。
※2022年1月現在の情報です。
