パラレルの開発について

今回はパラレルの開発に関しての記事を書きたいと思います。

どんな技術構成なのか？を知りたい方に是非読んでいただければと思います（あくまであらゆる検証を最短で行うための最小構成で開発しており、まだまだ整っていない部分が多いというのはご容赦ください）

パラレルについて

なぜパラレルを作ったのかというはこちらの記事を見ていただければかと思いますが、今回の記事は技術観点で何が面白いのかを書きたいと思います。

パラレルを構成する上で重要なポイントは主に下記です。

① 基本構成

② リアルタイム通信

③ 通話技術

この三つを中心とした構成になっております。

① 基本構成

フロントエンドはiOSがSwift、AndroidがReact Nativeで開発しており、バックエンドはRuby on Rails、インフラはGoogle Cloud Platformを利用してます。

基本Docker上で動いており、コンテナにAPI Serverを置いてKubenetesで動かしているという構成です。

会社名がReactなので、パラレル以前に開発してきたアプリは全てReact Nativeでしたが、今回からは通話などネイティブレイヤーのコードを触る機会が多くなることを考えてSwiftで実装しました。（Androidはとにかくスピード優先でJavaやKotlinを触ったことなかったのでRNで実装してます）

Googleのサービスは積極的に利用していて、DBはCloud SQL、BigQuery、Cloud Memorystore for Redis、ストレージはCloud Storage、監視はStackdriverなどを利用しているといった感じです。

特にFirebaseにはお世話になっており、Analytics、Cloud Firestore、Crashlytics、Cloud Messaging、Remote Config、Dynamic Linksなどなど多用してます。

② リアルタイム通信

パラレルは、基本的に二人以上で使うエンタメコミュニケーションアプリのため、下記のようなことをリアルタイムに処理する必要性があります。

ステータス、チャット、通話、友達リクエストや承認などです。

こうした処理は現状WebSocketとFirebaseのCloud Firestoreを使って実現しておりますが、特にWebSocketについては同時接続数が増えてくると負荷が大きくなるためAWS AppSyncやFirebase Realtime Databaseを利用することを検討しています。（他にも良い方法があれば是非教えてください！）

当初はRails5.0から登場したAction Cableを利用していたのですが、出たばかりでまだ文献が少なかったことや実際に利用してみて不安定なことが多かったため、現在はOSSを利用してWebSocketの通信はハンドリングを行っています。

③ 通話技術

通話についてはWebRTCを応用した技術を持つ会社のSDKを活用してます。かなりカスタマイズ性に優れているSDKなので、I/Oの前処理や提供されているオプションの組み合わせで各スマホ端末に合わせてカスタマイズして活用してます。

ここに関してはサービスの根幹部分になるため公開記事としては言及はこれまでに控えさせていただきます。

困っていること

スピード優先で開発を進めてきたツケが回り始めているタイミングで、同時接続の桁が増えてきたあたりから現状の構成だと厳しくなってきてるなーと思う部分が多くなってます。

最近では秒間のクエリ数が跳ね上がる時間帯（21時〜1時）でのDB負荷が急増して2日連続で一時的にサービスダウンしてしまうこともありました。スケールアップとスケールアウトでなんとか凌いでますがもっと効率的なやり方がないかと頭を捻らせてるところです。

エンジニア募集！！

iOS/Androidネイティブエンジニアの方、ユーザー規模の多いリアルタイム通信（チャットやステータスなど）経験者、負荷分散などの有識者の方など全方位で採用しておりますので是非ともお気軽にお声がけください！

https://twitter.com/Joaoki