OpenIdeaのGCPプロダクトの調査と選定

赤羽洋祐
2018年5月18日
読了時間: 4分

初めまして。OpenIdeaでサービス開発を担当することになりました、てってぃです。さて、自己紹介はあまり得意ではないのでスキップして肝心の本題に参りましょう！

この記事の目的

OpenIdeaのwebサービス開発設計にあたってGCPプロダクトの選定から始めることになったので、調査と選定のまとめをしました。バックエンドの世界に両足を踏み込むのは初ですが、OpenIdeaと一緒に勉強していきたいと思います。これから投稿させていただく記事はOpenIdeaが成長していく記録です。

使えそうな（面白そうな）GCPプロダクト

Kubernetes
BigQuery
Firebase
Spanner

1. Kubernetes（公式）

アプリケーションの機能をコンテナで分割して各々で管理することで、マイクロサービス開発を実現する。

利点

アプリケーション管理が容易かつ互いの機能への影響を抑制できる
アプリケーションの展開・拡張・管理が容易に！

懸念点

コンテナ分割しすぎると管理の難易度が飛躍的に上昇しそう
全体像の把握が初期設計者以外には高難度

導入事例

https://cloudplatform-jp.googleblog.com/2018/01/Google-Cloud-Platform-Mercari-kubernetes.html

2. BigQuery（公式）

ビックデータをインポートしてクエリによる自動解析を行う

利点

スケールの膨大さ
インポートしたデータに対してSQLを叩くことで自動解析が可能
SQLさえ叩ければエンジニア以外でも利用可能

懸念点

実際にどんなデータを集計してどんな用途に使用したいのか決めておかないとBigQuery破産が発生する

導入事例

http://techtarget.itmedia.co.jp/tt/news/1708/09/news07.html

3. Firebase（公式）

シンプルさを追求したmbaasプラットフォーム

利点

クロスプラットフォームの開発に長ける
認証も安全で簡潔に書ける
テストやアナリティクスなどの環境も万全

懸念点

利用性の高さ故、開発に利用するユーザが多い
少しお高め

導入事例

【6月OPEN】https://komer.co/

https://www.alibaba.com/

4. Spanner（公式）

トラフィックに対してノードの自動割り当てによる高パフォーマンスと最適化を実現する

従来的な関係データベースとNoSQLデータベースの両方の長所を取り入れて、トランザクションの一貫性（整合性）とスケーラビリティの容易さの両方を実現している

利点

多量のトラフィックに対してのパフォーマンスが保証される
ノードの割り当てを自動で最適化
上記の処理に対しての高い信頼性

懸念点

使用するノード数によってはかなりお高い
リカバリの手段がない（現バージョンではある可能性あり。より調査が必須）
設計における制約が多数存在
負荷実験に時間を要する

導入事例

https://www.fulcul.com/

GCPプロダクトを用いた開発例

Spanner + BigQuery + α
Flutter + Firebase + α
FireBase + Kubernetes + α
その他

1. Spanner + BigQuery + α

多量のトラフィックの中で詰まらず高速でレスポンスを返したい！

RDBMSと分散データベースの良いとこ取りをするSpannerは最適

利点

大量のクエリが発行されてもSpannerによって詰まることがない

懸念点

ノード単位で課金され、かつ高価なので設計ミスやチューニング不足の負担が相当
最新の技術使用かつノード数を減らすためのスキルが求められるのでかなり挑戦という印象

2. Flutter + Firebase + α

google製言語とGCPプロダクトのコラボレーション

利点

google製最新言語とgoogle製サーバーレスプラットフォームで最小最速の開発
お互いgoogle製なので相性が良い
Firebaseに関してはドキュメントが多数存在

懸念点

Flutterは言語としてbetaの機能が多々あるので予測外の問題が生じる可能性がある
しっかり設計、バージョン固定* 要件によってはflutterで満たせない場合がある

3. FireBase + Kubernetes + α

利用が簡単なFirebaseとマイクロサービス開発のためのコンテナ分割でKubernetesを合わせる

利点

Firebaseは開発において比較的難度が低いため、適応に時間を要しない
アプリケーションの機能自体をKubernetesによってコンポーネント指向風に開発

懸念点

開発難度や利用数からして技術的魅力を高められない可能性

4. その他

Angular + Kubernetes + α

OpenIdeaにおける利用プロダクト案

安定策：Firebase + Kubernetes + α

技術的魅力が決して高いとは言えませんが、開発工数は他プロダクトよりかからない印象です。また、知見のあるエンジニアさんも比較的捕まりやすいでしょう。工数やスキル等を考慮して安全策をとる場合にはこちらの安全策を考えます。

挑戦策：Spanner + Kubernetes + BigQuery + α

こちらは技術的魅力が豊富なので実際に形にできただけでも一注目集められるかな。と。ただ、その分要求スキルは高くなり求められるエンジニアも限られるでしょう。また、設計上様々な制約もあり、Spannerを設計するにはSpannerのみに集中できる人材が必要になってくると思われるので、非常に挑戦的なプロダクトです。しかし、僕は開発メンバーとして”技術の魅力溢れるサービス”を作ることにチャレンジしていきたいです。

感想

今回、OpenIdeaの開発をするにあたって、”0から設計をする”というのは初めての経験になります。今まではフロントエンドを中心に触れていたため、バックエンドの世界であたふたした毎日を過ごしています。第一の目標はGCPと連携してデプロイまでの導線を作れるようになること。目先の目標はサービスのダイアグラムを視覚化することです。成長を楽しみながらやっていきたいと思いますので、よろしくお願いします！