オープンロジを支える技術（2022年版）

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

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

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

今年も締めくくりとして一年の技術的なアップデートをまとめておきたいと思います。

### 過去のエントリー
- [オープンロジを支える技術（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. GCPと機械学習を活用したサービス開発の実現
3. SREチームの組成と横断的な技術課題解決への取り組み強化

### 1. 新アーキテクチャーによる新サービスのリリース

創業期からこれまでモノリシックな構成でシステムが積み上げてきており、システムの肥大化に伴い変更コストやメンテナンスコストが徐々に高くなってきている課題をを解決するため、新しいアーキテクチャーを構成するプロジェクト（コードネーム：fraise）を一昨年立ち上げ、昨年はインフラ基盤の設計〜構築を中心に進めていました。
今年に入って、新アーキテクチャー上での運用を前提とした最初のサービス開発が始まり、無事リリースまで実現することができました。

まだまだ限定的な展開であり、また新たな課題も出てきていますが、技術的には大きな一歩を踏むことができたのではないかと思っています。

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

- [Amazon ECS](https://aws.amazon.com/jp/ecs/)
- [AWS CloudFormation](https://aws.amazon.com/jp/cloudformation/)
- [Terraform](https://www.terraform.io/) 初めは CloudFormation を利用していたが徐々にこちらにシフト中

### 2. GCPと機械学習を活用したサービス開発の実現

オープンロジではAWSをメインのインフラ環境として利用しているのですが、GCPは BigQuery の一部社内用途レベルの限定的な利用にとどまっていました。

まだリリース前の案件ではあるのですが、現在機械学習を活用したプロジェクトが進行しており、GCPのサーバレスサービスを活用した構成で開発しています。

オープンロジには「テクノロジーを使い、サイロ化された物流をネットワーク化し、データを起点に物の流れを革新する」というビジョンがありますが、このビジョンに一歩近づく取り組みでもあり、技術的にも既存の仕組みにとらわれない開発として良いチャレンジができていると感じています。

#### このプロジェクトで導入された主な技術

- [Vertex AI](https://cloud.google.com/vertex-ai) マネージドな機械学習のプラットフォーム
- [Cloud Function](https://cloud.google.com/functions)
- [Taurus](https://gettaurus.org/) 負荷テストフレームワーク

### 3. SREチームの組成と横断的な技術課題解決への取り組み強化

これまでインフラチームという名前で存在していたチームなのですが、日々の対応・運用に追われてなかなか大きな課題解決に取り組むことが難しい状態になっていました。
一方、日々ユーザーは増えサービスは成長しプロダクトも大きくなっていく中、今後のスケーラビリティを担保するためにも横断的な技術課題をしっかり進めていくことが必要だと考え、体制強化しSREチームと名前を変え新たにチームを編成しました。

その結果として今年はとくに監視運用周りの整理とパフォーマンス周りの改善を進めることができました。
まず Datadog がすでに導入されていたもののあまり活用できてない状態だったので、現状把握や異常検知できるように監視環境を整備してもらいました。
また、想定を超える規模のユーザーが増えてきたことによりパフォーマンス劣化によるストレスを与えてしまうことが目立ってきたところに対して、指標を定めボトルネックを特定しプロダクトチームと連携とりながら改善を進めることができました。

まだまだ課題山積ですが、今後解決すべき横断的技術課題の優先度整理も進んできたので、来年はより本質的な課題解決に着手していきたいと思っています。

#### 関連記事

- SREチームリーダー大平の登壇記事
    - [『ソフトウェアアーキテクチャ・ハードパーツ』の視点から見たオープンロジのアーキテクチャ改変事例](https://note.openlogi.com/n/n0a3e17acbb6c)

## 主な技術スタック

今回は主要な使用技術のみピックアップする形にします。

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

今年はライブラリ類のバージョンアップができなかったので、来年は対応していきたい。

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

### インフラ環境

#### Amazon Web Services (AWS)

今年は円安の進行により想定以上にコスト増となってしまいました。
旧来のクラシックな環境（EC2+RDS）に加え、新アーキテクチャー基盤としてコンテナーベースでの環境（ECS+Aurora）も追加されました。
並行して運用環境ごとにアカウントを分けるマルチアカウント対応も行いました。

#### Google Cloud Platform (GCP)

前述の通り、本番提供用の環境としての活用がはじまりました。
データ基盤はまだまだ未整備なところが多く、来年はここら辺の整備も進めていきたいと思っています。

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

### 運用監視

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

### 開発環境

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

### 情報ツール系

- [Google Workspace](https://workspace.google.co.jp/)
- [Slack](https://slack.com)
- [Redmine](https://www.redmine.org/)
- [Redash](https://redash.io/)
- [GROWI](https://growi.cloud/)
- [Notion](https://notion.so) 試験的に導入中

## まとめ

今年はエンジニアマネージメント体制が強化されエンジニアの採用も進んだことにより、これまでなかなか進められなかった大きな施策を着実に進められるようになってきました。来年はさらに体制強化しボトルネックとなっている技術課題の解消を進め、より本質的なものづくりができる環境にしていきたいと思います。

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