執行役員 VP of Engineering 兼技術部長の @hsbt です。今年は Ghost of Tsushima をプレイしてからオープンワールドのゲームをひたすら消化していて、今はアサシンクリードヴァルハラでイングランドを歩き回っています。
昨年から今年にかけては以下のエントリーのようにGMOペパボ(以下、ペパボ)の社内のIT環境やリモートワークの状況について紹介しました。
今回は社内IT環境から離れて、ペパボがサービスに採用している技術スタックについてご紹介します。
はじめに
ペパボの技術スタック、について紹介すると書きましたが、ペパボという会社は事業部制を採用しており、運営しているサービスは事業部に紐づけられ、所属している人員によって開発が行われます。そのため、技術スタックについて何を採用し、廃止するか、は事業部ごとのエンジニアリングマネージャであるシニアエンジニアリングリード(以下、SEL)が決定します。
SELには、VP of Engineering である私や CTO である @antipop から技術方針や戦略について共有し、所属している事業部のビジネスを拡大するために最適な技術スタックを選択する権限を付与しています。原則としてSELが決定した事項を採用しますが、全社の技術方針や戦略に明らかに異なる場合のみ意義を唱えてストップすることはあります。
今回はそのような中で選択されてきた技術スタックについて、おおよその雰囲気がわかる粒度で紹介します。
バックエンド
データベースとデータのやりとりを行い、後述するフロントエンドやモバイルアプリケーションへ必要なデータを送るバックエンド層については、Rails やフレームワークを用いない PHP を採用しています。特に新たにサービスやコンポーネントをリリースする際には、マーケットの反応を速く見ることができる点とアップグレードなど社外環境に合わせての進化が容易なため Rails を採用することが多いです。一方、PHPは歴史が長いサービスやコンポーネントで利用されており、新規に採用することは少ないものの、採用する際には Laravel を利用しています。サービスによっては Golang も使っています。
原則として、言語の開発チームによってサポートされているバージョンを用いることを開発のポリシーとしています。Ruby の場合、新しいバージョンにすることで得られる言語体験とパフォーマンスメリットを重視し、バージョンは 2.6 または 2.7 にアップグレードを積極的に行っています。PHPの場合、新規に開発することが少ないため、独自にビルドして新機能を追いかけずに OS で提供されている PHP インタプリタのバージョンを用いることが多いです。
バックエンド層は OpenStack を用いて構築しているプライベートクラウドの nyah や AWS、Heroku などの上で動かしています。nova(OpenStack におけるコンピュートリソース) や EC2 のような昔ながらのVMを用いて、インスタンスを立ち上げ、アプリケーションのデプロイを行っています。デプロイツールはほとんどのプロジェクトで Capistrano を用いています。 minne やカラーミーショップの一部では k8s への移行を進めており、それらのサービスでは nyah の上に構築した k8s クラスタである nks と AWS の eks の二つで透過的に動くマルチクラウドの環境を実現しています。
フロントエンド
Rails を積極的に採用してきたこともあり、フロントエンド層では多くのサービスで jQuery や erb, haml, slim などを用いています。中には backbone.js や CoffeeScript など 2020 年には役目を終えたと言える技術要素も残っており、これらをユーザーには影響を出さずにモダンな技術要素へ置き換えていくことが現状の課題です。
新たにフロントエンド層についてコードを書くときには TypeScript を用いています。フレームワークについては、ここ数年で構築されたアプリケーションでは Vue.js や、一部で Angular を使っていましたが、新たに構築する場合は React と Next.js を用いています。Vue.js や Angular 作られているアプリケーションを React へ置き換えるということは計画していません。
全社共通のペパボのデザインシステムもシニアデザイナによって作成している途中です。また、デザインシステムの実装である CSS フレームワークも開発しています。これらを用いることでサービスそれぞれの特色は出しつつ、スタイルの世界観をペパボで共通にできるようになる見込みです。
インフラ
先述したとおり、ペパボでは自社の DC に OpenStack を用いて nyah と呼ばれるプライベートクラウドを構築しています。nyah はエンジニアであれば、開発用であっても常識的な範囲で誰でも自由にコンピュートリソースを利用できます。OpenStack 自体の盛り上がりが国内ではやや小康状態になってますがペパボでは先述した nova、ブロックストレージの cinder、ネットワークリソースの neutron の三つを主に使っているため、他のクラウドサービスへも透過的に移行できる状態になっています。パブリッククラウドサービスとして AWS/GCP/Heroku なども利用しています。今年は特に nyah と AWS の二つで冗長化したマルチクラウドのプラットフォームの構築を推進しています。
インフラのオーケストレーションツールとしては、Terraform を用いており、AWS から提供される cdk などは用いていません。OpenStack の場合は独自に開発した yaocloud を用いることもありますが、計算を行わない時は OpenStack の場合でも Terraform を用いています。コンピュートリソースを作成した後のプロビジョニングには、 Chef や Puppet を用いています。ローンチ後の歴史が長いサービスは Puppet を用いていますが、新たに作成する場合は Chef を用いることが多いです。Terraform, Puppet, Chef のいずれも継続的にバージョンアップを行い、新しい機能を積極的に使うようにしています。
データベースは MySQL を採用しています。一部、PostgreSQL を採用しているサービスもありますが、パフォーマンスチューニングなどの継続的な改善活動を行うにあたって、グループ内にもアドバイザーが在籍しており、メリットが得られることから強いこだわりがなければ MySQL を選択しています。データベースは nyah 上に MySQL インスタンスを立ち上げて利用することが多いですが、AWS との専用線である Direct Connect を用いて RDS/Aurora で構築することもあります。また、KVS は Redis か memcached を利用しています。AWSフルマネージドでサービス構築は現状行っていないのでDynamoDB のような OSS として提供されていないミドルウェアは採用していません。
モバイル
モバイル層では iOS の場合は Swift, Android の場合は Java を用いています。Android は新規にクラスを作成する場合には Kotlin も用い、すでに存在するコードについても書き換えを推奨していますが置き換えの具体的なロードマップはまだありません。一方で iOS については、Objective-C で書かれているコードを Swift に置き換えるという作業はひと段落し、Swift のみ用いた開発体制となっています。来年以降は SwiftUI の導入も計画しています。SUZURI など、新たにモバイルアプリケーションを提供する場合はプロトタイピングの速度を重視して Flutter を採用しています。現時点では今後も利用する予定ですが、クロスプラットフォームのフレームワークでは難しい局面になった場合は Java か Kotlin への置き換えも視野に入れています。
モバイルから呼び出す各種 API としては、REST API から GraphQL への移行を進めています。そのため、モバイルエンジニア向けに API 開発や呼び出しについての勉強会なども開催しています。近年ではモバイルアプリケーションでの権限制御についての考慮を設計段階から行う必要性が高まっているため、シニアモバイルエンジニアによる権限制御のガイドラインの作成を行っています。このようなドキュメントに限りませんが、ペパボでのモバイルアプリケーション開発は個人の力量に頼ってしまうことが続いてきたため、事業部を跨いだ開発のプラットフォームとして共通で利用できるCIやワークフローの自動化を推進している途中です。
データ分析
ペパボでは bigfoot と呼ばれるデータ集積・分析基盤 を開発しています。従来は TreasureData 社のプラットフォームの上で動かしていましたが、今は GCP の BigQuery を中心とした構成に移行しました。今後、GCP のみを使うか、AWSやプライベートクラウドの nyah を用いるかはまだ決まっていません。2021 年以降に実現したいサービスやプロダクトの要求に応じて適したプラットフォームを選択する予定です。データ分析に関わるコンポーネントの管理には Apache Airflow を用いています。Airflow も今後継続的に使っていく決定版、というものではなくマルチクラウドでデータプラットフォームを作るときに最適なツールは内製も含めて検討を進めています。
データ分析に限った話ではありませんが、Severless プラットフォームも積極的に利用しています。Lambda, Cloud Run の何かを使う場合が多いですが、開発補助的な位置づけであれば GitHub Enterprise の GitHub Actions を cron として利用して計算処理を実行することもあります。Severless プラットフォームで用いる言語としては、アプリケーションであれば Ruby、データ分析であれば Python を使うことが多いです。一時期、JavaScript を用いていたこともありましたが、デプロイツールの変更の追従に時間を取られることとユースケースに合わせたライブラリについてのキャッチアップが必要となったため現在は Docker ベースのコンテナに Ruby か Python の環境を用意してデプロイを行っています。
データ分析の結果として応用されることが多い検索エンジンは Elasticsearch を用いています。しかし、普通に使っている、というレベルにとどまっているので効果的に使っていくという取り組みやプロジェクトを全社横断で立ち上げたところです。
セキュリティ
セキュリティ侵害などに対する取り組みとしては、セキュリティ対策室という専門の部署を設け、日々新たに発番される CVE のトリアージやインシデント未満の事象について、脅威レベルの検討などを行っています。サービスで用いられるサーバーのインベントリ管理として、wazuh を導入しています。wazuh 単体では通知やサマリを見るためには使いにくい面があるため、専用の Rails アプリケーションを内製して、数千のサーバーの構成の状況を Slack などを通して把握できるようにしています。
また技術スタック、ではありませんが、毎年事業部ごとに一回以上インシデント訓練を行っています。この訓練も以前はセキュリティ対策室がリードして行っていましたが、2020年時点では仮想のインシデントを計画してハンドラーなどの役割設定なども全て事業部内で完結するようになっています。今後は、より効果的にインシデント対応が行えるようにサイバーインシデントだけではなく、防災や防衛などで用いられてきたインシデント対応のフレームワークも応用しながら、訓練の内容もアップデートをしていく予定です。
開発プロセス
開発プロセスは全社でスクラムまたはスクラムのプラクティスの中から一部だけ、例えばプロダクトバックログを取り出して利用する、ということを推奨しています。サービスによっては JIRA や Notion のガントチャートなどを利用している場合もありますが、共通用語としてはスクラムで用いられるものを使っています。
コード管理はプライベートクラウドの nyah に構築している GitHub Enterprise Server と GitHub Enterprise Cloud を用いています。基本的に全ての開発は pull-request を用いて作成し、一人以上のレビューを行ったのち、デプロイ用のブランチ(master や deploy など)にマージをしてデプロイを行います。サービスによっては自動でリリースタグを打ってロールバックや APM での変化を把握しやすいように工夫しています。
まとめ
以上、思いつく限りでペパボの技術スタックについてご紹介しました。内製でサービスを複数運営していることから、インフラからモバイル、それらに付随する様々な技術スタック全てを俯瞰すると幅広いことがわかります。現在在籍しているエンジニアで、紹介した技術スタックそれぞれ得意な領域を重ね合わせるようにしながら日々ユーザーに使ってもらえるようなサービスを開発しています。
もし、技術スタックを見てペパボのエンジニア採用に興味をもった方のうち、以下に該当する方はペパボという会社の開発組織はおすすめの環境と思います。
- バックエンドとモバイル、インフラとデータ分析、など技術レイヤーを跨いでコードを書いたり、サービスを開発することが好きな方
- OSS を利用するだけではなく、不具合の調査や開発などをサービス開発と区別をしないで取り組むことが好きな方
- すでに動いているサービスの漸進的なアップデートや、マイグレーションが好きな方
逆に以下のような方には、現在のペパボの環境はあまりおすすめではないかもしれません。
- 決められた範囲や決められた言語、環境の中でコードを書くことが好きな方
- ベンダ製品など、手順書と保証が整備されているプロダクトの導入や社外対応が得意な方
- 常に新しいサービスを発展段階の技術スタックを用いて構築することが好きな方
向き、不向きのどちらが良い、ということではなく現在のペパボの状況としては最初に述べたような方に向いているという内容になりますが、後に述べたような取り組みでもビジネスがスケールするようにペパボの技術スタックをコントロールしていくことが私 VP of Engineering の仕事と思いますので引き続き取り組んで行こうと思います。