Edited at

appengine ja night #33 行ってきたのでメモ

More than 1 year has passed since last update.

togetter

動画


メルカリアッテを支えるAppengineとGolang

https://speakerdeck.com/ttsuruoka/merukari-atute-wozhi-eru-google-app-engine-to-golang

初めてAppEngine, GCPを触った

ソウゾウ&メルカリ 鶴岡さん


  • 新規サービスのインフラになぜGAE/Goを採用したか

  • 実際どうだったか


なぜGAE/Goを採用したか


  • スケーラブルな分散の仕組み

  • GCPの盛り上がり、将来性

  • Go言語がチーム開発に向いてる


スケーラブル

メルカリがグローバルだったので最初から要件が高かった。

複数リージョンでサービス展開

大規模アプリケーション

瞬間的なアクセス増に対応できないといけない

スケールするための準備を減らしたい

よくあるアプローチ


  • A. 過去の経験からインフラを使う

  • B. 新規設計


    • よくある方法。

    • メルカリは最初の3ヶ月のことだけ考えてやった

    • プロダクト作りに全リソースを注いだ



  • ハードル高いのでBほど思い切った方法もできなかった

Paasは?


  • GAE以外は?

  • 小さいところは規模的にリスクをコントロールしづらい

  • MS、Forceはアプリケーションの要件に合わなかった

GAE→要件を満たせた


  • グローバル

  • 大規模


    • Snapchatはすげーでかい。

    • Twitterよりでかい



  • ハイスケーラブル


GCPの盛り上がりの兆し


  • GCPよいとの声を聞いた

  • BigQuery, GCEくらいしか使ってなかった

  • Google担当者と話ができた


    • これ自体がすごい驚き

    • イメージなかった



  • AWSも東京リージョン内頃は技術担当者いなかった

  • GCPは直接話せる担当者がいる

  • ブログの更新頻度とか上がってる

  • Amazonより勢いがあると感じた


Golangサポート


  • 最初はPHPでやるつもりだった

  • Goどう?って言われた

  • それをきっかけに情報を集める

  • 生産性の高さは使われてるから認識していた

  • 特に不満点がない

  • ほとんど標準パッケージで作ってる

ちなみにPHPもサポートしてるんだけど、5.4系で古かったから最初からほとんど検討してなかった

GAE/Goにすることでメルカリに対して技術的な位置づけがハッキリして数年後の想像ができたのでよかった


実際にどうだったか


生産性

生産性大事。

世間一般で使われていくのか見極める必要があった。

採用とかに影響するので調べてた。

社内の詳しい人には相談せずに開発した。(意図的に)

関数型言語が盛り上がるけど普及しない。

こうすることでラインを越えるかどうか見極められる。

メッチャ速くて生産性高いって分けじゃなかったけど、初心者のわりに生産性は高いと判断。


スケーラビリティ&パフォーマンス

GAEアプリは正しく設計して実装した時点で負荷対策が完了している。

プッシュ通知で3000万とか送ると瞬間的にアクセスが跳ね上がる。

特に何もせずに自動でスケールしてくれる。

プロビジョニング、ウォームアップは不要。

ちょっと前まではプロモーションチームと事前に打ち合わせてたけど、これが不要になった。

GAE使えばどの言語でもこのパフォーマンスが得られるかといえば、そうではない。

Goだったからこそのパフォーマンス。


可用性

メルカリの時は負荷が高くなるとどうにもならなくなるときがある。

アッテは稼働率100%でいけてる。

ダウンタイムゼロ。

ちゃんと動いてるかどうかの監視が不要になった。

アッテはメンテや計画停止は予定してない。

GAEとDatastoreでやってれば普通にいけるレベル。


サポート体制

使ってみるしかない。

一番の懸念点。

すごい頻度で打ち合わせした。

有償サポート(GOLD)

地の利がある。

同じビルにいるからいい。

高度な質問しても一次回答がクッソはやい。

サポートGOOD


コスト

環境は1エンジニアで1環境

QA環境は企画の人とかが触って1100円。

こいつらは本番と同等の環境。

QAは社内で20人くらいがアクセス。

自動テストも走ってる。

メルカリ、アッテは99.9%は読み込み。

書き込みはほとんどない。

まだキャッシュ入れてない。

Datastoreはもっと減ると思う。

7月からDatastoreが安くなるからもっと安くなる予定。

インフラ専任がいないから人件費もゼロ。

どんなインフラを考えてもこんな安価にできるのは不可能。

AWSに比べてリザーブドインスタンスのような計画性が必要なものはないから常に安価な状態にできる。

シンプルにアクセスが増えればコストも上がる従量課金。

インスタンスも超気で使えば勝手に割り引き。


結論

誇張じゃなく全て満足


QA


フレームワークは?

検討したけどGoの哲学に合ってない。標準パッケージでまかなえた。

部分的にライブラリとかは入れたけど、フレームワーク使ってない。


Datastoreのバックアップとかは?

RDBから変えるときに悩んだ

RDBもある程度でかくなると完全な復元とかむり。

なので部分的に諦めていた

復元したデータにどれくらい意味があるか?

保険程度のもの。

バックアップ自体はBigQueryに入れてる。


Googleクラウドと App Engineで実現したドローン業務利用

エアロセンス 小早川さん、松本さん

工事現場とかでドローンとばしたりする会社

GKEとかも使ってる。

地図配信システムはGCP

人数がすげー少ない。

運用をほとんどせずに、高速に→App Engineしかない!


どうやって地図配信システムをGCPで作ったか

地図タイル

Webメルカトル図法。メルカトル図法の亜種。

Google Maps

正方形のタイルにした

割り切ったフォーマット。

国土地理院は世界的にも最先端。

会合とか行くとすげー面白い。

空撮画像をアップロードして、GAE/Goで画像処理してGCSへ。

GCSに上げて公開。そのままパブリックで良いならすぐできる。

公開データじゃないのでGAE/Go使って描画させている。

大量アクセスもGAE/Goでさばく。


地図データはラスタだけではない

ベクター形式の情報も最近は来てる。

GeoJSON


ANA GAEの事例

sinmetalさん

Olive

CA,整備士達などの従業員が利用

コミュニケーション容赦ないツール

元々そんなシステムが存在しなかった。

インカムでやりとりしてた。

こないだの障害発生したレイヤーとは別物。

そういう時のやりとりするためのツール

Enterpriseのシステムなのでユーザーは10万人程度。


なぜApp Engine?

Google Apps導入してるので、アカウント連携が楽。

どっかの空港が爆発するのなんて予測できない。

その時アクセス負荷で落ちたら話にならん。

グローバルであることが必要。

Olive作り始めたときはまだGCPってなかった。

元は

Google Groupsと連携してた。

フィルタリングしたかったのでバッチでユーザー見てそれをDatastoreに反映

OliveはGAE/Java

インスタンス起動時間は3,4秒。

10万程度なので余裕。

世界中どこからアクセスしてもおk

サーバーサイドが二人、フロント一人、ゼネラル一人の体勢

Appengine, Dアタstore、GCS, BigQuery

今後は…

最近Machine Learning系やろうとしてる。

入力するのがめんどい→音声入力

Push通知→Firebase使おう

App Engineの良いところ

小さいリクエストをたくさんこなす

REST APIを通して処理


非同期と分散

Task Queueがいい。

メッセージ受け取ったときに、App Engineで処理するとタイムアウトとかの可能性が上がる。

その場合はTQに入れて非同期処理。すぐOKを返す。

App Engineエンジニアはすぐにこのアーキテクチャを思い浮かべる。

普通のリクエスト・レスポンスしない。


Datastore Update

Cross Group Transaction

ネイティブでサポートするようになった。

25エンティティグループまで

爆発的な値下げ!


Pagination派苦手

Cursor使ってReadmoreでやった方がいい。


Kind設計

論理削除フラグ漬けるとカスタムインデックス作る必要になる。

Kind移動した方が楽。


QA


ANAで導入するとき抵抗はなかった?

元々Google Apps使ってたからそんなに抵抗がなかった


Datastoreで検索エンジンを作る

hogedaigoさん

App Engine好きだとなんでもAppEngine、Datastoreでやりたくなる病。

GrepをDatastoreでやるのは無謀。

なぜSearch APIつか湾の化?

たしかに便利だが…

スケールしない。

リクエストすれば200GBくらいまでは広げてもらえる。

→ Datastoreで実装しよう

ソートはできるだけしない、種類を減らすUIにする必要がある。(コストがかかるため)

Indexesに倍グラムで分けたデータを全部ツッコむ。

IndexesにのみEquality Filterが使えるようにしてる。

KeysOnlyにすると、無料で実行できるから安くできる。

条件がないときはALL。

予めIndexesにALLを入れておく。

余計なカスタムインデックスの作成を避けるため。


まとめ

よかった


  • 高速

  • スケーラブル

  • フルマネージド


    • メンテとか考えなくてもいい



悪かった


  • Entityのサイズ上限がある。


    • Entityの数は無制限だけど



  • LIKEできない


    • N-Gramで対応



  • Or inできない

  • ソートプロパティ

  • インデックス作成コスト


    • 7月以降の価格改定に期待




GAEを利用したソシャゲ開発事例

グッド・フィール 加藤さん

ほぼ何も知らない状態でApp Engine任された

初心者でもゲームとして動くよという事例

ボトルネックになった部分についての共有


なぜApp Engine

先のプロジェクトでApp Engineだったので引き継いだ