この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
本レポートは2016年10月27日(木)〜28日(金)に開催されたServerlessConf Londonのセッション"Globally Available Serverless Architectures"のレポートです。
発表資料
動画
なし
発表スライド
概要
テーマはサービスをグローバルに展開するときに気をつけるべきことは何か? 前半では課題や留意点が述べられ、後半ではサーバーレスアーキテクチャーでの解決方法が述べられています。
スピーカーの Rich Jones さんは Python のサーバーレスフレームワーク Zappa の作者ということもあり、後半では Zappa と AWS を前提に話が進みます。
グローバルサービスで注意すべきこと
1:Speed
サービスをUS内のリージョンで構築する場合、アメリカ国内の通信のレイテンシーは無視できる程度だが、東京との間では数百ミリセカンドにもなる。
地球上で物理的に離れたところから利用するユーザーもいることを意識すること。
2 Scalability
リージョンあたりのリクエスト処理能力の上限があっても、全リージョンにデプロイすれば、そのリージョンの数の倍だけ処理能力も増える
3:Redundancy
AWS も障害が発生しないわけではない インスタンスや特定のリージョンでサービス障害が発生するかもしれないが、全リージョンが全滅することはありえない 複数リージョンにデプロイしてリスクヘッジする
4:Security
会社の規定、物理インフラ、仮想インフラ、サーバー上など様々なコンポーネントがある 社内・社外の両方から脅威にさらされている
5: Regulatory compliance!
国によって法制度がことなる。 個人情報・金融・医療データはややこしいわかりやすい例
- アメリカのHIPAA
- EU圏のデータ保護規則
- PCI
などなど、準拠すべきコンプライアンスがある
ここまでのまとめ
同じ製品でも国によって準拠すべきコンプライアンスは異なる
Zappa/AWSを使ったサーバーレスアーキテクチャーでの解決
Zappa とは
- Api Gateway
- Lambda
をベースにしたサーバーレスフレームワーク。
スピーカーの Rich Jones が作者
アーキテクチャーの違い
従来:サーバーを常時起動し、各リクエストをWebアプリが処理 Zappa:API Gatewayを起動し、各リクエストに対してサーバーを起動し、Webアプリが処理。処理が終わったらサーバーは破棄。
後者ではリクエストとサーバーの数が同じ
サーバー運用費が劇的に下がる。
Zappa は WSGI ベースの Python アプリがターゲット。 WSGIベースのウェブアプリケーションであれば、ほぼコード修正なしにサーバーレスアーキテクチャーで実行できる
チャットやシンプルなAPIサーバといった小さなシステムだけでなく、Djangoで書かれたCMSのような重厚なシステムにも対応している。
Case study A: Globally Available API Microservice
世界中のどこからでも 200ms 以内にリクエストした人の緯度経度を返す。 メインロジックは数行
Flaskベースのアプリをサクッと Zappa に移行 ベータ機能ではあるがAWSの全リージョンにデプロイ可能
世界中のリージョンにデプロイしたサービスのルーティングについて
ルーティング
クライアントからはどの通信経路でアプリにリクエストさせるのか?
1 Simple, Stupid
方針:地域ごとに特定のホストにアクセスさせる 所見:ユーザーはそんなめんどいことはやりたくない
2 Latency
方針:通信の近さで振り分ける 所見:通信は早いが、コンプライアンスを無視してしまう。
3 Geolocation
方針:IPでエリアを特定し振り分ける 所見:コンプライアンスを満たすが、通信が遅くなる
4 Round Robin
方針:同じエリア内限定でラウンドロビンする 所見:負荷分散出来るが、通信が遅くなる
静的コンテンツであれば、CDN を使うとレイテンシーは下がる
Case study B: Globally Distributed Medical Service
コンプライアンスがうるさい医療データ処理システムをグローバル展開するにはどうすればよいか?
ハイブリッドアーキテクチャー
- HTTP(AWS API)/非HTTP(ファイル操作)の混在
- 永続化される(S3)/されない(API GW/SQS)インフラの混在
アーキテクチャー
Medical Data -> S3 -> Lambda -> SQS S3 -> Lambda -> SNS -> Doctor
永続インフラについて
満たすべきは以下
- セキュア
- 永続化される
- コンプライアンスに準拠
データベースが不要なシステムというのは極めて稀 データベースがある場合はどうすればよいのか?
データの管理方針
認証データ
- 中央に集約
- レプリカを各リージョンに展開
- ログインなどはローカルのレプリカを参照するのではやい
- 中央への書き込み時のみ遅い
医療データ
- 中央集約しない
- 各リージョン内に完結してデータ管理
まとめ
Zappa を使うと
- 時間を節約し
- 低コストに
- グローバル展開するサービス
をデプロイ出来ます。
感想
楽しめるトークでありながら、何故か動画がYouTubeに公開されていません。
撮影のトラブルによるものであり、インターネットに公開するとまずいことを発言したわけではないと思います。
7
