Pairs海外版におけるシステム構成の変遷を暴露するぜ

この記事は eureka Engineering Advent Calendar 2017 の7日目の記事です。
6日目は 坂田さん の「Pairs Infra 2017」でした。

自己紹介

はじめまして。PairsのGlobalチームでエンジニアリングをコソコソしてます @takochuu です。
プロジェクトマネジメントと、サーバーサイドの実装をメインに担当しています。お手柔らかにお願いします。

概要

実はPairsは日本向けのアプリケーションだけではなく、今年9/28に韓国へ向けてアプリケーションの提供を開始しました。
今回は韓国版を提供するにあたって変更したシステム構成の内容ついて書きたいと思います。

本題の説明に入る前に、韓国版のアプリケーションを提供する前まで、Pairsをどのように開発していたのかと、システム構成について解説します。

ソースコードの管理

サーバーサイド

サーバーサイドは一部展開国に依って分岐があるものの、同じリポジトリのソースコードで動作しています。
海外版を開発するチームの人数もエンジニアが10人以下という少人数で開発をしているため、日本版で開発された機能を効率的に取り込む事が目的です。

日本版と海外版はそれぞれ国によってAPIサーバーのホストが分かれており、リクエストを受け付けるサーバーを切り分けており、
起動時のオプションに応じてデータベースの接続先などを環境変数から読み出しています。

ネイティブアプリ

ネイティブアプリについては元々日本版と同じリポジトリで開発していたものの、去年12月から今年の6月に行ったGlobal版ネイティブアプリのフルスクラッチを行い、今は別々のソースコードになっています。
こちらの解説については、@yuyakaido のこちらの記事が詳しいのでご覧になってください。

これまでのシステム構成

PairsはFacebookと連携したアプリケーションであるため、レイヤとしては以下が存在しています。(細かいミドルウェアは割愛します)
1. ネイティブアプリ / Webフロントエンド
2. Facebookアプリ
3. サーバーサイド
4. データベース

日本版と台湾版をこれまで提供してきたのですが、システムは全く別物として管理されており
お互い疎結合で運用してきた歴史があります(図1)。しかし、韓国版をリリースするにあたって、いくつかの観点を踏まえて海外版のシステム構成から考え直す必要があると判断しました。


図1

変更後のシステム構成

上記のようなシステム構成で動作してきたPairs海外版でしたが、韓国へリリースするにあたり新しいビジネス要件が発生します。
今後新しい国に展開する可能性も踏まえて先々のビジネスに対してデメリットがあってはいけない。という要件と、 韓国市場に展開するにあたり、迅速にリリースをしなければならない、というビジネス要件です。

上記を踏まえて、先に述べたシステム構成(図1)で動作していたアプリケーションを以下(図2)のように変更することに決定しました。

具体的には、ネイティブアプリのバンドルID / アプリケーションIDを同一にしていることと、同一のFBアプリを使用していることが大きな変更点です。


ネイティブアプリを同一にしていることについては、分けてしまうともし今後アプリを同一にしたい場合に課金情報の引き継ぎができないことが理由で、同一FBアプリにした理由としては
FBのapp_scoped_idが重複してしまうことによって今後データの取り回しが悪くなることを恐れてのことです。

図2

システム構成を決めた上で、同じネイティブアプリを使用する関係上、決めておかなければならかった点について解説します。

新規登録 / ログインについて

DBを分割するという判断をしたため、アプリを初回起動したタイミングでどちらのホストに登録・ログインをするのか決める必要がありました。

Apiサーバーについては韓国 / 台湾でホストが分かれているため、登録しているかどうかを返すAPIを実装し、各ホストに対して登録されているかを確認するリクエストを発行することで、新規登録かログインなのかを判断しています。

また、どちらのホストにも登録がなければ登録できる国を一意に定める必要があります。

端末から得られる情報(MMC)をサーバーサイドでハンドリングして、登録すべき国を一意に定めることによって、問題を解決しました。

翻訳について

翻訳の管理についてはベストなソリューションは決まっていませんが、goのテンプレートで必要な部分と、Webview(js)で必要な部分と、ネイティブアプリで必要な部分を分けて管理をしています。

サーバーサイドについてはgoを起動するタイミングで、オプションを付加することにより言語設定を切り替えられるようにしていますが、今後は動的に返す言語を変更したいところです。
※翻訳の管理でイノベーティブな管理方法をお持ちの方は教えてください。

おわりに

このシステム構成の変更が吉と出るか凶と出るかは韓国版を提供し始めたばかりなので結果が出尽くすのはもう少し時間はかかると思いますが、今のところ困っていないので問題になっていません。
これから先に他の国に展開するタイミングでこのシステム構成の真価が問われるのではないかと考えています。



エウレカは、日本にいながらグローバル環境での開発を体験できる非常に珍しい職場だと思っています。
少しでもこれからのグローバル展開に興味をお持ちであれば是非ランチやカジュアルにオフィスに起こし頂ければと思います！


次回は竹内さんの「GKE+CircleCI 2.0で継続的デプロイ可能なアプリケーションをシュッと作る」です。お楽しみに！