AWSで経営分析基盤を構築

  • 投稿カテゴリー:Blog
  • 投稿者:

目次

自己紹介、案件概要

はじめまして、アークエルデジタルのAKI(アキ)と言います。
インフラがコアスキルのAWSエンジニアです。
以前はベンチャー、大手Sier、製造業でインフラSEとして活動していました。
昨年12月にアークエルにJoinしました。

今回は「AWS基盤を用いた経営管理システム」を構築したお話をしたいと思います。
お客様は九州を中心に事業を展開されている、大手エネルギー会社様。
グループ関係会社を含めると50社近く、さらに多くの営業拠点もお持ちのため、必然的にクラウド前提でのシステム案件となりました。
次年度に大規模な組織再編が控えていらっしゃるため、再編後の各会社の経営情報を俯瞰するニーズがありました。
そこで、各会社から収集したデータを加工して分析できる経営情報ダッシュボードが見れる仕組みを構築することとなります。

プロジェクトは約1年前からスタート。お客様にとっても初の試みで手探りの部分も多いため、少人数の開発体制でスモールスタート。プロトタイプの画面を実際に触っていただき、レビューをもらい、徐々にブラッシュアップを繰り返してきました。
途中、インフラ基盤にも関わる追加要件がありクラウド基盤ごと再構築しましたが、当初からCloudFormationで構築していたことが奏功し、最小限のダウンタイムで遂行できました。

システム概要

クラウド基盤にはAWS、データ分析アプリとしてTableau(タブロー)を採用しました。
データのインプットにはkintoneを利用しています。
kintoneからAWSへつなぎ、蓄積させたデータを元に2段階の構造化を行い、最終的にTableau上で経営情報ダッシュボードを見せる仕組みです。
利用しているAWSサービスはEC2、S3、RDS(Aurora)、Apigateway、CodeCommit、CodePipeline、CodeBuild、CloudFormation、Lambda、StepFunctionsになります。
ユーザーにはデータ入力者、閲覧者のロールがあり、開発側(弊社)でも管理者、開発者のロールがあります。
ユーザーは100〜200程度。拠点によりWAN経由またはVPN経由でのアクセスとなります。端末は主にWindows PCですが、今後はタブレット端末も視野に入れています。
データ処理の開発にはCodeシリーズを使っています。

構築上のポイント

AWSのマネージドサービス、サーバーレスを最大限活用しました。
前述ですが、基盤構築の効率化のため最初からCloudFormationを活用しました。整合性を保ちつつスタックで構築、管理できるのは効果大きいです。途中、基盤が再構築となった際にも威力を発揮しました。
Tableau特有ですが、AWS Backupでのバックアップ・リストア運用では不十分です。ライセンス上の問題で、単純な復元はライセンスが壊れた状態になります。Tableauのオンラインドキュメントを参照して、「バックアップファイルのエクスポート+CloudFormationでEC2再構築の準備」で対応しましょう。ライセンスは試用版の想定で同時に3サーバーまでアクティベーションできます。不要となったライセンスは削除するのをお忘れなく。
開発面ではパラメーターストアを使って効率化を図った点でしょうか。
当たり前といえば当たり前なのですが、開発が終盤になるにつれ、効果を発揮します。
開発効率を下げないためにも大事な点かと。セキュリティ面はマネージドサービスのSecurity Hubを活用しました。セキュリティ基準はCIS(CIS AWS Foundations Benchmark v1.2.0)に準拠させています。
また、固定IPを持たない小規模拠点からの接続のためクライアントVPNを構築しています。接続に必要な証明書は一意でユーザー特定できるよう、個別に作成・配布しています。

各要素の説明 - 基盤

(VPC)
サブネット設計は8つ。通常は6つが多いと思うのですが業務要件を受け2つ増やしています。
パブリックサブネットにはbastion(踏み台サーバー)のみ設置しています。
TableauをインストールするEC2はプライベートサブネットに設置し、ALBでアクセスを受ける仕組みにしています。
本システムがオープンウェブサイトではなく、イントラネットに近い扱いとなることから直接IPを付与しないようにしました。
あとはDB用のプライベートサブネット、その他業務要件のサブネットです。

(ALB/NLB)
通常のアクセス(https)はALBで。DNSは外部にありましたのでRoute53は使用せず、外部DNSのCNAMEレコードにALBのDNS名を設定することでアクセスさせました。固定IPを持つ拠点からのみアクセスを受け付けるよう制限しております。
またTableauをインストールした際、TSM(Tableau Service Manager)接続用に自己証明書が生成されるのですが、この接続はポート番号がSSL(443)、http(80)以外のため、ALBではなくNLBを使うことで回避しました。

(EC2)
TableauをインストールするためのEC2、あとは踏み台サーバーなどです。
ミニマムスタートでしたので、マルチノード(分散構成)ではなくシングルノード(単一構成)です。
インスタンスタイプも最低スペックを満たすレベル(m4.2xlarge)で構築しました。

(RDS)
RDSはAuroraのPostgreSQL。2インスタンスのClusterになります。

(API Gateway)
kintoneとの接続用にAPI Gatewayを作成しています。
Regionalタイプのシンプルなものです。

(Lambda/Step Functions/AWS Systems Manager パラメータストア)
データ取り込みや処理のためLambdaを作成し、StepFunctionsでつなげています。
パラメータの扱いを効率化するため、パラメータストアも使用しました。

各要素の説明 - アプリ

主にETL処理、DB設計、分析画面(Tableau)などの開発です。
こちらは開発担当がお客様と頻繁に連携を取り、改善サイクルを限りなく高速で回していくことでブラッシュアップさせていきました。

インフラの再構築が入った時も、使用停止を最小限に留めるよう務めました。
再構築に伴うダウンタイムは全て1日以内に押さえています。
そのため、お客様と開発メンバーがTableau画面に触れられる環境を最大限維持できたことが開発に大きく貢献したと思っています。

その後、いくつかの課題が発生するたびに再構築を繰り返しました。
再構築のたびに細かい動作不良(文字化けなど)が発生しましたが、サポートを活用するなどして解決しています。
「基盤再構築によるTableauサーバーの更新」
1)WindowsからLinuxへの再構築
2)Tableauのバージョンアップ(20201→20203)
3)VPC移行に伴う再構築。この時点で最新バージョン(20204)になりました。