OPENLOGI を支える技術（2023年版）

# オープンロジを支える技術 2023

[OPENLOGI Advent Calendar 2023](https://qiita.com/advent-calendar/2023/openlogi) 最後の投稿です。

[株式会社オープンロジ](https://openlogi.com/corp/)は2013年12月25日が創業日なのでちょうど本日で創業10年目という節目を迎えることになりました。

今があるのもひとえに、ここまで関わってくれた多くの方々（お客様、パートナーの皆様、株主の皆様、過去および現在の全てのメンバー）のおかげです。

そんな感謝の気持ちを携えながら今年も締めくくりとして一年の技術的なアップデートをまとめたいと思います。

## 過去のエントリー

- [オープンロジを支える技術（2022年版）](https://qiita.com/migrs/items/c89d0559d822836d79c5)
- [オープンロジを支える技術（2021年版）](https://qiita.com/migrs/items/e4c8cf6ef8ad20d5b645)
- [オープンロジを支える技術（2020年版）](https://qiita.com/migrs/items/6eea6866f7bfcfeb595f)
- [オープンロジを支える技術（2019年版）](https://qiita.com/migrs/items/8e38b959c343bbecc47f)
- [オープンロジを支える技術（2018年版）](https://qiita.com/migrs/items/dab171ee613f0c278596)
- [オープンロジを支える技術（2017年版）](https://qiita.com/migrs/items/b1bfd752d3abb0101f59)

## 今年の主なアップデート

今年実施された技術的なアップデートでインパクトが大きかったものを３つピックアップしました。

1. フロントエンドビルド環境の分割とライブラリのアップデート
2. CI環境周りを中心とした開発基盤の大幅な改善
3. Datastream for BigQuery の導入

### 1. フロントエンドビルド環境の分割とライブラリのアップデート

これまでサーバーサイドのバージョンアップには対応していましたが、フロントエンド関連ライブラリの更新は著しく遅滞していました。

そうなってしまった要因として、一つのビルド環境でシステム全体のフロントエンドを構築していた点が挙げられます。
初期的にはこれで良かったものの、システム規模の拡大に伴い、影響範囲が広がり、アップデートやメンテナンスが困難な状態に追い込まれていました。
この事態を解消するため、まずモジュールごとにビルド環境を分割し、影響範囲を最小にし、メンテナンスが容易な環境の構築に取り組みました。
その成果として、各種ライブラリは最新のものに更新され、これまで活用したいと思いつつも利用できなかった React Hooks も取り入れることができるようになりました。
この一年は、社内でReact勉強会が開催されるなど、フロントエンド周りの盛り上がりが目立つ一年となりました。

#### この取り組みで導入された主な技術

- フロントエンド開発環境改善
  - ドメインモジュール毎にビルド単位分割
  - React バージョンアップ v15 → v18
  - [TypeScript](https://www.typescriptlang.org/) の導入
- 各種ライブラリの導入
  - フォームライブラリ    
    - [React Hook Form](https://react-hook-form.com/)
      - [Redux Form](https://redux-form.com/) からの刷新
      - Redux は最小限の利用にとどめる方針に
  - バリデーションライブラリ
    - [yup](https://github.com/jquense/yup)
    - 独自実装からの脱却

### 2. CI環境周りを中心とした開発基盤の大幅な改善

これまで最低限のCI/CD環境は確保されていましたが、その改良が進まずに形骸化していた状態が続いていました。
そんな状況の中、新しく入ったメンバーからの課題提起と提案により、次々と改善が進み開発基盤の大幅強化が実現しました。

取り組みの内容については今年の開催された [PHP Conference Japan 2023 で発表](https://fortee.jp/phpcon-2023/proposal/07decf85-670a-4ec0-936b-5c51a4547e14) されたのですが、登壇者(@takeokun)による解説記事がありますので詳しくはそちらを参照ください。

- [PHPConf2023「保守性の高いアプリケーションを作り続けるための基盤整備について」というテーマで登壇します](https://zenn.dev/openlogi/articles/bba928c9e07af3)

#### この取り組みで導入された主な技術

- Linter/Fomatter 周りの強化
  - [php-cs-fixer](https://github.com/PHP-CS-Fixer/PHP-CS-Fixer) / [ESLint](https://eslint.org/) / [Prettier](https://prettier.io/) のアップデートと適用範囲の拡充
  - [actionlint](https://github.com/rhysd/actionlint) / [secretlint](https://github.com/secretlint/secretlint) の 導入
- 静的解析関連ツール
  - [PHPStan](https://phpstan.org/) / [Larastan](https://github.com/larastan/larastan)
    - 仮想サーバー上のレガシーシステム に対して Level 5 まで適用
    - 新アーキテクチャー（コンテナ）上のモダンシステムに対して Level 9 (Max) まで適用
  - [Rector](https://getrector.com/)
    - ASTベースの自動リファクタリングツール

### 3. Datastream for BigQuery の導入


2019 年頃から BigQuery は主にダッシュボードの作成やデータ分析に用いられてきました。
Embulk を使用して RDS のデータを BigQuery にロードする実装が運用の基礎となっていました。

しかし、このシステムはリアルタイム性やデータ信頼性の観点から見ていくつかの問題点を抱えており、積極的な導入に踏み切れずにいました。しかし、[Datastream for BigQuery の発表](https://cloud.google.com/blog/ja/products/data-analytics/introducing-seamless-database-replication-to-bigquery)により、探していた理想的な解決策が出現したと感じていたところ、SREチームやDataチームの協力により、その導入を実現することができました。

導入経緯などについては、データエンジニア(@akabe)による以下の記事が詳しいのでそちらを参照ください。

- [Datastream for BigQuery を本番導入しようとしている話](https://zenn.dev/openlogi/articles/survey-datastream-for-bigquery)

BigQuery を本番データベースとほぼ同等の感覚で使用できるようになった結果、データ利用の可能性が大幅に拡がりました。特に、ニアリアルタイム性とデータの信頼性の向上により、倉庫オペレーションといったクリティカルな用途でも活用可能になりました。

#### この取り組みで導入された主な技術

- データロード
  - [Datastream for BigQuery](https://cloud.google.com/datastream-for-bigquery?hl=ja)
- データ変換・クエリー実装
  - [dbt](https://www.getdbt.com/)
    - データ基盤構築の標準ツールとしてメイン利用
  - [Dataform](https://cloud.google.com/dataform?hl=ja)
    - Looker Studio ベースのダッシュボード開発で部分的に活用
- IaC
  - [Terraform](https://www.terraform.io/)
    - Terraform 職人が増え Data チーム による GCP データ基盤構築でも活用が進んだ

## 主な技術スタック

### アプリケーション関連

- [PHP](http://php.net/)
- [Laravel](https://laravel.com/)
- [React.js](https://reactjs.org/)

今年は初期から停滞していたフロントエンドのバージョンアップを無事実現。
サーバサイドのバージョンアップの準備も粛々と進めており、来年には実施予定。

### インフラ環境

#### Amazon Web Services (AWS)

レガシーな仮想サーバー環境と新アーキテクチャーによるコンテナ環境の並行運用しています。
レガシー環境における RDS の Aurora化プロジェクト粛々と進めており、来年には移行実現できそうです。

#### Google Cloud Platform (GCP)

BigQuery を中心としたデータ基盤を運用。
レガシーな Embulk 環境から Datastream for BigQuery を中心とした新たなデータ基盤構築に取り組んでいます。

- [BigQuery](https://cloud.google.com/bigquery/)
- [Vertex AI](https://cloud.google.com/vertex-ai) マネージドな機械学習のプラットフォーム

### 運用監視

以前よりも Datadog の活用が進み、何かあったら Datadog を見る習慣が根付いてきた気がします

- [Datadog](https://www.datadoghq.com/)

### 開発環境

Copilot 活用している人と Terraform 職人が増えてきた

- [GitHub](https://github.com/)
- [GitHub Actions](https://github.co.jp/features/actions)
- [GitHub Copilot](https://github.com/features/copilot)
- [Ghost Inspector](https://ghostinspector.com/) E2E テスト環境
- [Terraform](https://www.terraform.io/)

### 情報ツール系

ここらへんは特に変化なし。プロジェクト管理ツールはリプレイス検討したい。

- [Google Workspace](https://workspace.google.co.jp/)
- [Slack](https://slack.com)
- [Redmine](https://www.redmine.org/)
- [Redash](https://redash.io/)
- [GROWI](https://growi.cloud/)

## まとめ

今年は新たに仲間入りしたメンバーによる活躍が目立った一年でしたが、その背景には経験豊富なメンバーたちの堅実なサポートがあったからこそであり、その相乗効果によりここまで大きな改善を進めることができたと感じています。

10年も経つとさすがにシステムのところどころで歪みが目立つようにもなってきました。
この問題に関してもCTO室において技術負債解消のための特別チームも組成され、解決に向けて動き始めています。
次の10年はよりビジネスを加速させるシステムを追求していきたいと思います。

オープンロジでは、これからのチャレンジを一緒に楽しめる[仲間を募集](https://corp.openlogi.com/recruit/)しています。興味ある方はぜひお気軽にご連絡ください！