システムの一部をAWSからGCPへ　Sansanのクラウドアーキテクチャの裏側

AWSとGCPのマルチクラウド活用

大澤秀一氏：それでは「AWSとGCPのマルチクラウド活用」というテーマで発表させていただきます。よろしくお願いします。

まずはじめに自己紹介です。

大澤秀一と申します。部署はDSOC（Data Strategy & Operation Center）というところで、主な業務としてインフラの運用・保守・改善などを行っています。

部署は通称「DSOC」で、シャツを着てるんですけど、ホームページを見るとR&Dエンジニアがいっぱい載っていますが、普通のエンジニアも在籍しています。

みなさん知っていると思うんですけど、このイベントのハッシュタグは「#SBB」なので、このセッションを聞いた感想とか、マサカリ（鋭い指摘のこと）とか、聞きたいことがもしありましたら、どんどんTwitterにツイートしてほしいなと思います。

僕はこのあと懇親会にいるので、直接捕まえて一緒にお話しさせていただければと思っています。

今日このセッションを通じてみなさんに知っていただきたいこととして、AWSとGCP両方の特徴を知って、有効活用するためのヒントを持って帰ってもらいたいと思っています。

AWS・GCPがどちらが良いとか悪いとかっていうのは今日はそんな話はしなくて、それぞれ良いところ・悪いところ両方あるかもしれないんですけど、それぞれ良いところをまず知ってもらい、両方使うためのヒントについて話ができればいいなと思っています。

今日はあんまり深い話はしなくて、両方すごい知ってガチが使っている人からすると「少々物足りないな」という内容となっています。

本日このアジェンダですが、まずタイトルにありましたとおり、名刺データ化システムとそのアーキテクチャついて概要をご説明します。

次に、その一部をGCPに移行した事例についてお話をします。その移行事例を通して得られた知見から各クラウドの特徴についてお話をして、最後にまとめに入りたいと思っています。

名刺データ化システムの概要

では、まず名刺データ化システムについての概要をご説明します。

私たちはこのシステムを「GEES」と 呼んでいます。このスライドの図では右側になるんですけど、この「GEES」と、法人向けクラウド名刺管理サービス「Sansan」と、個人向け名刺アプリ「Eight」は、別々のシステムで動いています。

私たちがスキャナーやスマホで撮った名刺画像は、Sansan・Eightから送られてきて、GEESの中で、OCRによる自動入力や人の手による手動入力を経て、SansanとEightにデータが送り返される仕組みになっています。

この自動入力における仕組みのアーキテクチャについて、このような図になっています。

ここでは全体の図のみで、次のスライドから詳しく見ていくんですけど、AWS・GCP、こういう風に両方動いていることを知ってほしいなと思っています。

まずAWSから具体的に見ていきます。スライドの関係上サービスを絞っているんですけど、本来はもっと多くのサービスを使っています。

私たちの方針として、運用コストを下げるためにできるかぎりマネージドサービスを使っていきたいという考えがあるため、AWSも同様に多くのサービスを使っています。

アーキテクチャは、シンプルな3層アーキテクチャに加えて、バッチシステムが動いています。Webは、主にオペレーター用の入力サイトとか、自動入力用のAPIが動いています。

Compute Engineに関しては、まだコンテナではない普通のEC2がメインで動いているんですけど、最近はECSとかAWS Batchといったコンテナの活用が増えています。

データベースに関しては、Amazon Auroraをメインに使っていますが、他にも用途に応じて、Redshift、DynamoDB、CloudSearch、Elasticsearchなどを使っています。

どんな用途で使うかと言いますと、例えばデータ化が終わった名刺データの解析とかで重いクエリを投げる用途としてRedshiftを使っていします。

あとは、新しいアイコンにはなかったんですけど、データ化フローの制御に、Simple Workflowを使っていて、名刺のデータ化のフローを制御しています。

GCPの構成

続いてGCPです。

名刺のデータ化のOCR処理プロセスの中でCloud Vision APIを使っています。Cloud Vision APIを採用している理由としては、高精度な認識結果を得ることができ、かつ運用コストを抑えることができるからです。

GCPに移行したサービスですが、ロードバランサーと、GCEと呼ばれているCompute Engineから構成されていて、かなりシンプルなアーキテクチャになっています。これらはRESTfulなAPIなんですけど、普通のAPIとは違って、高速にレスポンスを返すようなAPIじゃなくて画像データを解析した結果を返すので、かなりマシンリソースを消費するという特徴があります。

AWSで稼動していた時はc4.8xlargeで動いていて、1台あたりのスループットが秒間で0.8リクエストという、普通のAPIからしたらかなり低速なスループットとなっていました。

GCPにおけるLoggingなんですけど、Stackdriver Loggingによるログ収集を行っており、長期保存をする場合はGCSという分散オブジェクトストレージを使っています。GCPにおける操作履歴やネットワークトラフィックを保存するときにも、このようなサービスを使っています。

また、GCEのサーバ内における監査ログもログ収集を行っています。Linuxにおいてはauditd、Windowsにおいてはイベントログを、Loggingエージェントを介してログをパースして収集を行っています。

アプリケーションログは、AWS側にログ収集の機構があるため、AWSにある集約用のFluentdサーバに送っています。これに関しては、AWSのNLBにFluentdをくっつけて、VPN経由で送信しています。

AWS・GCP間の通信について

AWSとGCP間のデータ通信なんですけど、HTTPSによるインターネット経由とVPNの両方を併用しています。本来であればすべてVPNを介したほうがセキュアで安全なんですが、AWS VPNのスループットの上限があるため、こちらを考慮しています。

先ほどご説明したAPIは画像をPOSTするため、そこを使われてしまうとVPNの帯域を食い尽くしてしまう恐れがあるため、APIのリクエストはすべてインターネット経由にしています。また、AWSとGCP間のデータ通信で注意が必要なのは料金です。2つのクラウドともに、インターネットへ出ていくとき（アウトバウンド）に料金が発生します。

今回の移行において画像データを投げるので、そのデータ転送に関する料金はもちろんかかるんですけど、そこは開発者の人が頑張ってくれまして、画像データの形式を変更することにより圧縮率を上げてデータ転送量を抑えることによって、コストダウンを図ってくれています。

あとは、最近AWS側でデータ転送料金が約30パーセント下がったのがより追い風になって、コストダウンにつながっています。

AWSからGCPへの移行

ここまでが名刺データ化システムにおけるアーキテクチャの説明でした。次に、既存サービスにおけるGCPへの移行の話についてご紹介をします。

EC2からGCEへの移行に関しては「CloudEndure」というサービスを使っています。こちらのサービスは、CloudEndure Agentをインストールすることによってクラウド間でデータをレプリケーションをするため、リアルタイムでその設定が反映されるという特徴があります。

これによって移行がかなり楽になるんですけど、注意がもちろん必要です。当たり前なんですけど、EC2とGCEでサーバの中の設定は違うので、その環境に合わせて設定を変える必要があります。

こういった手間が意外と面倒くさいので、それをしたくないのであれば、普通はChefとかAnsibleを使って、1からプロビジョニングしたほうが早いですが、例えば、コード化していないサーバであったり、サーバ固有の設定が入ってしまっているとか、そういったサーバならCloudEndureを使ったほうがよいかなと思っています。

続いて、Auto Scalingなんですけど、普通のGCEインスタンスに加えて、「プリエンプティブVM」という24時間以内にシャットダウンされる代わりに8割引になるインスタンスがあります。これを使うことによってコストダウンを図っています。

スケールアウトするしきい値は、普通はCPU使用率で80パーセントになったらスケールアウトするとか、そういった設定をすると思いますが、今回はそれではなく、スループット（秒間に捌けるリクエストの数）によるスケーリングの設定をしています。これによって、そのアプリケーションの性能に即したかたちになるので、より効率的にスケールアウトできます。

GCPのオートスケールはAWSに比べてまだまだ機能が足りない部分が多いのでツールでカバーしています。例えば、スケジュールベースのスケーリング機能はGCPはまだ対応していないので、ツールを作って、cronで「何時になったら何台上げる」という風に設定しています。

最近GCPでCloud Schedulerというマネージドのcronサービスが出たので、今後はそちらに移行する予定です。

各クラウドの特徴

今回はロードバランサーとオートスケーリングとGCEというだけで、かなり限定的な移行事例でしたが、この事例を通して得られたポイントについてご紹介していきます。

まずCompute Engineなんですけど、AWSの特徴はなんと言ってもインスタンスタイプが多種多様であることが挙げられます。例えば、コンピューティングに最適化されたC5、メモリに最適化されているR5、GPUを積んでいるP3・G3などがあります。これらをうまく使うことによって最適なワークロードを実現することができます。

しかし、インスタンスタイプによってCPUとメモリが決められているため、例えば「CPUもうちょっと欲しいんだけどな」「メモリもうちょっと欲しいんだけどな」というときには、1つ上のインスタンスタイプに上げる必要があります。

GCPの場合は、CPUとメモリは自分で好きに選べるカスタムマシンタイプというのがあるので、必要な分だけのリソースを使うことができます。ただしその反面、CPUの性能が画一的であるため、CPUをフルで使いたい場合、AWSのC5に比べるとクロック数がやや落ちるので、スループットが落ちることがありえます。

また、Linuxの場合なんですけど、起動時間が早いという特徴があります。起動スイッチオンにしてから約1分以内にHTTPがつながるのでスケールアウトが早くて助かっています。

ネットワークとロードバランサーについて

続いてネットワークです。

AWSのVPCネットワークはリージョンに基づく考えがあるので、他リージョンを使う場合はリージョンごとにVPCを作ってペアリングする必要があるので、敷居はやや高いかなと思っています。

その代わりというとなんですけど、事業要件でリージョンを縛りたいといった場合には、VPC内のサービスはそのリージョンに基づくため、安心感はあります。

逆に、GCPはリージョンの敷居がかなり低くて、サブネットにリージョンが紐づくので、あるリージョンを使いたいといった場合には、そのリージョンのサブネットを追加するだけで使えるようになります。

リージョン縛りの要件がある場合に意図しないで他のリージョンを使ってしまうこともあるので、注意が必要かなと思っています。

VPNですけど、GCPのVPNはトンネルを1個追加することごとに1.5Gbpsの帯域を得られて、トンネルが複数あるとトラフィックを分散してくれます。トンネルを増やせば増やすほど帯域は広がっていくので、拡張性は高いと言えます。

続いてロードバランサーです。

AWSの特徴としては、とにかくシンプルで使いやすいです。。ロードバランサーを作って、そこにインスタンスをつなげれば、すぐ使えます。

また、バックエンドインスタンスの負荷を見ていい具合に分散してくれます。例えば、あるインスタンスの処理が重くなっていたり、インスタンスタイプがバラバラであっても、ロードバランサーが負荷状況を見てくれて、負荷のかからないインスタンスにリクエストを分散してくれるので、インスタンス全体的に最適化されます。

GCPは設定要素が多いので設定が難しい面があるんですけど、そのメリットとして、プレウォーミングが不要であったり、複数リージョン間でリクエストを自動的に割り振ってくれるので、1つのリージョンが落ちたとしても、自動的に他のリージョンへリクエストを振ってくれます。

あとは、バックエンドにGCSを使えるので画像データとかの静的コンテンツをGCSにリクエストを流すこともできます。

その代わりですけど、GCPのロードバランサーはゾーン内のインスタンスへのリクエストはラウンドロビンで均一されています。一部のインスタンスが重い処理があったとしても構わずリクエストを振ってしまうので、CPU使用率をみるとばらつきがかなり大きいことがあります。

プライシングについて

続いてコストです。

クラウドを使う上でコストは重要な要素なんですけど、2つのクラウドともにお得に使える仕組みが用意されています。

AWSは、「スポットインスタンス」という、EC2の需要と供給に応じて最大90パーセント割引で使える仕組みがあります。また、スポットインスタンスを拡張した「スポットフリート」というのがありまして、CPUとメモリを指定するといい具合にスポットインスタンスを自動的に作ってくれます。

継続的に割引を使いたい場合は、リザーブドインスタンス（RI）を購入します。コンバーチブルRIを買うことによって、インスタンスファミリーの変更もできます。また、AWSアカウントを一括請求に紐付けることによって、余ったリザーブドインスタンスが他のAWSアカウントに割引が効くということもできます。

GCPは、先ほど説明したプリエンプティブVMというのがあって、こちらは80パーセント近く割引で、値段固定となっています。

あと、おもしろい特徴としては「継続利用割引」という、稼動時間に応じた割引や、CPUとメモリをコミットすることで割引できる「確約利用割引」というのもあります。

AWSとGCPのセキュリティを比較する

最後にセキュリティです。

個人で使う分にはいいんですけど、企業で使うときに注意することとしては、データ保存時の暗号化があります。

AWSは、暗号化サポートされているサービスは多いんですけど、新規で作るときにはデフォルトで暗号化されていないで明示的に指定する必要があります。いったん非暗号化してしまったあとに暗号化するといった場合には、変更が難しいサービスもあります。

GCPの場合は、ほぼすべてのサービスがデフォルトで暗号化されています。

ユーザー制御と権限管理に関しては、両方ともIAMというサービスがあって、AWSはグループ機能とか細かい制御が可能なんですけど、GCPはまだグループ機能がなかったりとか、細かい制御はβ版でまだまだ不十分だったりするのでAWSのほうが融通が利くかなと思っています。

最後にまとめに入ります。このセッションを通じて、AWSとGCP両方の特徴を知っていただいて、有効活用するためのヒントを少しでも持って帰っていただけたら幸いです。

以上で発表を終わりにします。ありがとうございました。

（会場拍手）