1 of 42

クラウドってなんだろ？

クラウドを活かすアプリケーションの設計とは？

GCPUG Admin

Google Developers Expert

Mercari / Merpay Solution Team

@sinmetal

goo.gl/X54o2S

https://gcpug.jp

2 of 42

クラウドってなんだろ？

データセンター上に存在するハードウェアリソースをAPIを利用して、動的にリソースを借りることができる仕組み。

柔軟に迅速にリソースの提供を受けるために、料金はだいたい従量課金制で、使ったリソースの料金を払う。

2

https://gcpug.jp

3 of 42

クラウドは何がうれしいのか？

  • H/Wを調達するイニシャルコストがかからない
  • H/Wをリプレースする必要がない
  • いつでもマシンリソースの構成を変更できる
    • 負荷に合わせて増減
    • 月末だけ追加
    • CGのレンダリングや機械学習する時だけ
    • リリースする時だけ2倍のリソースを用意

3

https://gcpug.jp

4 of 42

クラウドのレイヤー

  • SaaS（Software as a Service）
  • PaaS（Platform as a Service）
  • DBaaS (Database as a Service)
  • FaaS (Function as a Service)
  • IaaS（Infrastracture as a Service）

4

言葉はどんどん増えていってる

https://gcpug.jp

5 of 42

クラウドは何がうれしいのか？

  • クラウドサービスで提供してもらうレイヤーも選択できるし、組み合わせを行うこともできる
    • Web API -> App Engine
    • 動画のエンコード -> Compute Engine
    • 動画の保存 -> Cloud Storage
    • ログの解析 -> BigQuery

5

https://gcpug.jp

6 of 42

クラウドは壊れないのか？

  • クラウドサービスが構築されているデータセンターにはもちろんH/Wが存在し、日々壊れていっている。
  • SLAのAvailabilityはリージョンやゾーン全体が落ちたのが対象になっているので、1つのインスタンスがエラーを返したものは含まれない

6

https://gcpug.jp

7 of 42

クラウドは不死鳥のように蘇る

  • クラウドサービスは壊れないのではなく、壊れてもすぐ蘇るもの
  • H/Wが壊れても、すぐ別のH/Wでもう一度生成してくれる
    • ただ、その瞬間そのH/Wで動いていたものは失われる

7

https://gcpug.jp

8 of 42

クラウドを活かすには？

  • アベイラビリティを上げる
    • クラウドサービスは瞬間的に壊れるのを前提に設計する
      • リトライ
      • リクリエイト

8

https://gcpug.jp

9 of 42

リトライ

  • 間にネットワークが入れば、エラーは起こる
    • いろんなレイヤーでリトライしよう！

9

アプリケーション

ストレージ

データベース

キャッシュ

リトライ！

リトライ！

https://gcpug.jp

10 of 42

リトライ

  • クラウドのサービスにはレプリカが存在するものが多い
  • 1つ壊れても、他のものたちが応えてくれる
  • でも、壊れる瞬間に繋いでいたものには応答が返ってこない

10

アプリケーション

ストレージ

ストレージ

ストレージ

クラッシュ

クラッシュした瞬間送ったリクエストにはレスポンスが返ってこない

https://gcpug.jp

11 of 42

リトライ

  • 適切なタイムアウトを設定して、リトライする

11

アプリケーション

ストレージ

ストレージ

ストレージ

クラッシュ

3秒待ってもレスポンスが無ければ、リトライする

https://gcpug.jp

12 of 42

冪等性 (1)

  • リトライ時に複数データを作成してしまわないように冪等性を考える

12

アプリケーション

データベース

data : A

key : 1

error

data : A

key : 2

リトライするたびにデータが増えてしまう

https://gcpug.jp

13 of 42

冪等性 (2)

  • リトライ時に複数データを作成してしまわないように冪等性を考える

13

アプリケーション

データベース

key : 1

data : A

key : 1

data : A

error

key : 1

data : A

key : 1

data : A

同じ場所を上書きするようにする

https://gcpug.jp

14 of 42

冪等性 (3)

  • Keyを最初に決めて、同じ場所を上書きするようにする
  • すでに更新されていたら、処理をスキップする

14

本来の冪等性は操作を複数回行っても結果が同じになることを指すけど、実際には操作を複数回行っても不都合が起きなければ問題ないことが多い。

https://gcpug.jp

15 of 42

リクリエイト (1)

  • 自分のアプリケーションが乗っているH/Wが壊れたら？

15

Compute Engine

Instance

My Application

Compute Engine

Instance

My Application

別のH/Wで再起動される

https://gcpug.jp

16 of 42

リクリエイト (2)

  • 複数インスタンス用意しておく
    • 自分のアプリケーションが0台にならないように
  • 起動にかかる時間を短くする
    • なるべく早く役割を果たせるように
  • 状態はなるべく持たないようにする
    • メモリは消し飛ぶので、状態はなるべく外へ

16

https://gcpug.jp

17 of 42

リクリエイト (3)

  • 役割を小さくして、初期処理を少なく
  • クラッシュした時の影響範囲を限定的に

17

Load Balancer

static contents

api

movie

movie

api

static contents

storage

storage

database

database

cache

cache

マシンスペック

アベイラビリティ

スケーラビリティ

トラフィック

リリース頻度

https://gcpug.jp

18 of 42

クラウドを活かすには？

  • パフォーマンスを上げる
    • 非同期処理
    • 分散処理

18

https://gcpug.jp

19 of 42

非同期処理, 分散処理 (1)

  • 同期的に処理する必要がない処理は非同期に処理した方が安くパフォーマンスを上げれる

19

User

Application

App Engine Confを登録

App Engineに興味があるUserにNotificationを送りたい！

Notification送信...

Notificationをすべて送り終わるまでレスポンスが返ってこない

https://gcpug.jp

20 of 42

非同期処理, 分散処理 (2)

  • 非同期に処理をする時に便利なのがQueueのサービス
  • GCPだとCloud Pub/Sub, App Engine Task Queueがある

20

User

Application

App Engine Confを登録

Queue

Notification Taskを登録

レスポンスを返す

https://gcpug.jp

21 of 42

非同期処理, 分散処理 (3)

  • Queueを挟むことで、処理の粒度でWorkerを分離できる
    • Workerのマシンスペックを変更できる
    • Workerの生成タイミングを遅延できる
    • Taskの管理をQueueがしてくれる
      • Workerへの割当
      • リトライ

21

https://gcpug.jp

22 of 42

非同期処理, 分散処理 (4)

22

User

Application

Confを登録

Queue

Taskを登録

レスポンスを返す

Worker

Taskの割当

Taskの数に合わせてWorkerの数を変更

Taskが0件の時はWorkerも0台でよい

Cloud Pub/Sub, App Engine Task Queueを利用すれば、運用はGCP任せ

Taskのリトライ, 割当, 残数

https://gcpug.jp

23 of 42

非同期処理, 分散処理 (5)

  • 非同期処理, 分散処理をする時に気を付けること
    • タスクを小さくしておく
      • リトライ範囲を小さく
      • 分割してたくさんにしないと分散できない
      • 巨大なCSV -> たくさんの小さなCSV

23

https://gcpug.jp

24 of 42

TaskQueueとプリエンプティブVMを利用して、動画の加工処理を行う分散アーキテクチャ

Task�Queues

Media Storage�Cloud Storage

Meta Data & Workflow�Cloud SQL

Meta Data & Workflow�Cloud Datastore

Media Processing�Compute Engine

Preemptible

Asset Mgmt & Sharing�App Engine

Autoscaling

Upload / �Download Media

Cloud Network�W/ Edge Cache

Media Storage�Cloud Storage

Object Change Notification

Resize Instance group size

24

The Products logos contained in this icon library may be used freely and without permission to accurately reference Google's technology and tools, for instance in books or architecture diagrams.

25 of 42

コンパクトな環境

  • 必要な時に必要なだけリソースを用意するには、環境がコンパクトな方が便利
    • Container
      • Docker
      • Borg (Google内部のみ)
    • Binary
      • Go

25

https://gcpug.jp

26 of 42

高速なネットワーク

  • 分散したタスクの分配や、コンテナの配備のために、高速なネットワークが必要

26

https://gcpug.jp

27 of 42

めんどうだったら

  • GCPのフルマネージドサービスにある程度任せてしまおう
    • App Engine
    • BigQuery
    • Cloud Dataflow

27

GCPのフルマネージドサービスはクラウドに最適化されているものたちなので、アーキテクチャはとても参考になる。

https://gcpug.jp

28 of 42

Google App Engine

  • Web ApplicationのためのPaaS
  • 非常に高いスケーラビリティ
    • デフォルトでオートスケール
  • Versioning
  • Task Queue

28

https://gcpug.jp

29 of 42

App Engine Architecture

29

Google Datacenter

App Engine Services

Google

Frontend

App Engine

Frontend

Static Server

Pending Request Queue

App Server

Datastore

Memcache

Task Queue

Search

URL Fetch

Socket

自分のDeployしたApplicationが動いている場所

https://gcpug.jp

30 of 42

Google BigQuery

  • データを分析するためのフルマネージドサービス
  • SQLを利用してインタラクティブな分析が可能
  • TB単位のデータでも数秒でフルスキャン

30

https://gcpug.jp

31 of 42

Google BigQueryは、なぜはやいのか？

  • データを元から分割して大量のHDDに保存している
  • クエリ実行時に動的に数千台のインスタンスを起動する

31

https://gcpug.jp

32 of 42

Colossus

  • Googleが作成した分散ファイルシステム
    • Google File Systemの後継だが、名前だけが公開されていて、中身は謎

32

https://gcpug.jp

33 of 42

Colossusの雰囲気

33

File

1

2

3

4

1

1

2

2

3

3

4

4

1

3

Fileを分割して複数のDiskに複製して保存する。

​

https://gcpug.jp

34 of 42

Dremel Architecture (BigQueryの裏の仕組み)

HDDから秒間読み込めるデータ容量は百数十MBなので、データを予め100MBほどに分割して、別々のHDDに保存しておく。

クエリ実行時に、必要なテーブルが保存されているHDDに対してDremel Nodeを割り当て、分散処理を行っていく

Dremel Node

Jupiter Network

Storage

Storage

Storage

Storage

Storage

Dremel Node

Dremel Node

Dremel Node

Dremel Node

Dremel Node

Dremel Node

Dremel Node

Dremel Node

Dremel Node

Dremel Node

Dremel Node

Dremel Node

Dremel Node

Dremel Node

Root Node

HDDにHotspotがある場合に備えて、同じファイルを複数のStorageに問い合わせて、最初にレスポンスが返ってきたものを採用している

34

35 of 42

列指向ストレージ

  • 分析時にすべてのカラムを読み込む必要があることは少ないので、カラムごとに分けて保存して、クエリに必要なカラムのみ読み出している
    • カラムの型が決定されるので、圧縮効率も最適化できる

行指向

列指向

35

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

​

https://gcpug.jp

36 of 42

Dremel

SELECT

state,

COUNT(1) AS count

FROM

`bigquery-public-data.samples.natality`

WHERE

year = 1987

GROUP BY

state

ORDER BY

count DESC

​

36

https://gcpug.jp

37 of 42

Dremel v1 Query Processing

37

Leaf

Leaf

Mixer1

Colossus

Jupiter

Leaf

Leaf

Mixer1

Mixer0

Leafはそれぞれ取得したデータに対して以下を実行してMixerに渡す

​

year = 1987

COUNT

GROUP BY state

MixerはLeafから取得したデータに対して以下を実行して、上のMixerにわたす

​

COUNT

GROUP BY state

http://gcpug.jp

38 of 42

Google Cloud Dataflow

  • パイプライン処理をフルマネージドで行うサービス
  • バッチ処理、ストリーミング処理、どちらも可能
  • Java or Python SDK (Apache Beam)

38

https://gcpug.jp

39 of 42

Google Cloud Dataflow

39

https://gcpug.jp

40 of 42

Google Cloud Dataflow

  • BigQueryではやりにくい処理を任せられる
    • SQLではやりづらいこと
      • 形態素解析
      • 外部のAPIの実行
      • 入力されたデータを複数の場所に出力
    • ストリーミング処理

40

https://gcpug.jp

41 of 42

Thanks you

Slackで待ってます！

https://slack.gcpug.jp

41

https://gcpug.jp

42 of 42

Resources

Google Cloud Platformの謎テクノロジーを掘り下げる

Google Cloud Storage: tips for reliability, performance and scalability (Google Cloud Next '17)

Google Cloud Dataflow(Python) Overview

42

https://gcpug.jp