脱Excel！数万行の巨大ファイルをAWS×スプレッドシートで「使い回せるデータ基盤」を目指した話

【🎄Merry Christmas🎄 WWWAVE アドベントカレンダー　12/21の記事です】

こんにちは、グロースエンジニアリンググループの塚本です。
以前、AWS JumpStartの参加レポートを投稿しました。
今回は、その続編とも言える実践編です 。
テーマは、「膨大なExcelデータのAWS移行と再利用可能なデータ基盤の構築」。
AWS上にデータ基盤を構築し、BI分析を目指したプロジェクトの裏側、特にアーキテクチャ設計で学んだ内容を中心に共有します。

プロジェクトの始まり

「Excelで管理しているある商材の販売データをDBにして、BIツールで分析したい」
という要望がきっかけでした。
Excelの中身を確認して、私は驚きました。
そこにあったのは、”数万行、数十列”に及ぶ巨大なExcelファイル。
まさにExcelの限界に直面している状態でした。
この依頼を受け、本プロジェクトが始動しました。
ヒアリングからアーキテクチャの実装まで一気通貫で実施しましたが、本記事では特に深い学びを得たアーキテクチャにフォーカスして共有します。

アーキテクチャのこだわり

実際に作成したアーキテクチャ図はこちらです。

単に動く物を作るのではなく、大きく分けて2つのこだわりがあります。

全体的な「脱office」を見据えたサーバーレス構成

全社的に脱Officeを進めていて、「Google スプレッドシート + GAS」への移行を実施しています。
本プロジェクトは、その先駆けとしての意味合いもあったため、UIには慣れているスプレッドシートを採用しました。
バックエンドは、運用負荷を最小限に抑えるために、極力サーバーレスで構成する方針で考えました。
また、スプレッドシートからs3への認証に関して、こちらを参考に構築しました。

「1回使い切り」ではなく「汎用的なデータ基盤」にする

当初、RDSを用いたDB構築を代表に相談した際、「今後の新プロジェクトでも使い回せる『基盤』として構築してほしい」という要望をもらいました 。
この視点を得たことで、「単なるExcelの置き換え」から今後発生する同様のデータ移行案件にも即座に転用できる「基盤」としての設計を追求しました。
具体的には以下の3点にこだわっています。

UI（入力）とBL（ロジック）の完全分離

ユーザーインターフェースであるGoogleスプレッドシートには複雑なロジックを持たせず、シートをcsvにしs3へアップロードする役割のみにしました。
実際のデータ加工やバリデーション、DB登録などの主要なビジネスロジックはすべてAWS Lambda側に集約しています。
これにより、将来的に別のPJでも同じようにスプレッドシートを作成するだけでデータ基盤を構築できるようにしました。

「設定の差し替え」で流用可能なクラス設計

lambdaの設計において、TableSchemaConfigというスキーマ情報を定義する静的クラスを用意しました。

# 概念イメージ：設定ファイルを変えるだけで異なるテーブルに対応
class TableSchemaConfig:
    SCHEMAS = {
        'titles': {
            'pk': 'id',
            'columns': [
                {'name': 'id', 'type': 'BIGINT'},
                {'name': 'name', 'type': 'VARCHAR'},
            ],
        },
        # 新しいテーブルが増えても、ここを追加するだけ
    }

このようにスキーマ定義とロジックを明確に分離することで、スキーマの変更時にロジックの修正を不要にすることが可能、また新しいプロジェクトで異なるテーブル構造を扱う際も、コード全体を書き換えるのではなく、 TableSchemaConfig 内のスキーマ情報をプロジェクトに合わせて変更するだけで、DB登録までのフローを再利用できるように設計しました。
※ロジック部分については、また別の記事でお話しします

CDKによる環境のテンプレート化

ネットワーク構成（VPCエンドポイント等）やLambdaの権限設定をすべてAWS CDKでコード化しているため、数行のパラメータ変更だけで、別のプロジェクトにも同様にセキュアで高コストパフォーマンスな環境を爆速でデプロイできる状態にしています。

学習と実務のギャップ：直面した3つの壁

学習用の環境では気づかなかった「実務ならではの壁」にもぶつかりました。

GUIではなく、CDKで構築する難しさ

これまでの学習では、マネジメントコンソール上で作業をしましたが、実務では再現性と運用性を重視しAWS CDKを採用しました。

実務レベルのコードをいきなり一人で書くのはハードルが高かったため、社内の専門グループ(DAG**※)**とペアプログラミングを実施しました。

熟練のエンジニアと共にコードを書くことで、インフラをコードで定義する方法やサービス毎の通信を行う為の設定（主にセキュリティ周り）について吸収出来たと感じています。

※DAG(Development Accelerate Group)については、こちら

「通信」と「セキュリティ」の壁

最も苦労したのがネットワーク周りです。
学習時はインターネットに繋がっていれば問題ありませんでしたが、実務ではセキュアな環境を構築する必要があります。
最もセキュアな情報を保持するDB(RDS)に関しては、プライベートサブネットに配置し、DBを操作するlambdaもプライベートサブネットへ配置する構成にしました。
すると、Lambdaが、S3やSecrets ManagerなどのAWSサービスへの通信が拒否される事態に。
原因は、プライベートサブネットからは直接インターネットに出られないこと。
この問題の解決方法を調べ初めて、VPCエンドポイント(Gateway型とInterface型の使い分け)を知りました。
VPCエンドポイントを導入することで、lambdaが、S3やSecrets Managerへ通信できるようになりました。
「とりあえず動く」GUI設定の裏側で、いかに多くのネットワーク設定が省略されていたのかを痛感しました。
苦労した分、AWSの裏側の仕組みへの理解が深まりました。

コストパフォーマンスについて

今回、あえて「東京リージョンではなく、オレゴンリージョン」を採用しました。

理由はシンプルにコストです。
今回構築するのは社内ツールであり、利用頻度も週1回程度、また利用ユーザー数は特定の方のみと限られているため、多少の通信遅延は許容範囲内であると判断し、より安価なリージョンを選定しました。
AWS Pricing Calculatorで見積もりを出し、「技術的な正解」だけでなく「ビジネス的な最適解」を選び取れたことは良い経験になりました。

所感

数ヶ月前、AWSに触れ始めたころの私は、各サービスの役割を個別に理解しているに過ぎませんでした。
しかし今回のプロジェクトを通じ、CDKを用いたインフラのコード化、拡張性を意識した設計、コストの追及に踏み込んだことで、AWSの捉え方が変わりました。
AWSを単なるツールとしてではなく、「価値を提供する」ための1つの手段として捉えるようになったと感じています。
今後も「技術的な好奇心」を「ビジネス価値」へと変換できるエンジニアを目指して挑戦を続けていきます。