こんにちは！ スタートトゥデイテクノロジーズ新事業創造部の塩崎です。 2018年7月24日〜26日にかけてサンフランシスコでGoogle Cloud Next '18が開催されました。 このイベントに新事業創造部の塩崎、今村、そして代表取締役CIOの金山の3名で参加してきました。
この記事では多数あった講演の中で特に印象に残ったものをいくつか紹介いたします。
講演
Building A Petabyte Scale Warehouse in BigQuery
DataWareHouse(DWH)のBigQuery移行をするために行ったことを各社さんが発表するセッションでした。 特にSpotifyさんの発表では移行のための具体的なtipsを4つ紹介されていました。 その4つの内訳は以下のものとのことです。
- Administration
- オンデマンド料金ではなく、定額料金を使う
- ビジネス的に重要なジョブ用にスロットを予約する
- Education
- ジョブのパフォーマンス監視のために、ジョブの並列度を監視
- Dremelのアーキテクチャ、特に伝統的なRDBとの違い列指向であることの理解
- Integration
- BigQueryのAPIを使用し、自社ツールを開発
- GCPサービス間でのデータ移動が簡単なので、他のGCPサービスと統合
- Partnership
- BigQueryのサポートチームに機能のリクエストを出す
また、Oathさんは各部署で独立してDWHを持っている（データサイロ）ために、部署横断的なデータ活用が難しいという課題があったそうです。 BigQuery移行のために、当時使用されていたHiveのデータをBigQueryにコピーし、BIツールであるLookerに繋ぎこむことから始めたそうです。 現在ではGCP製品をフル活用したデータ分析基盤になっているそうです。
TwitterさんはMySQL、Vertica、HDFS等に保存されたデータをBigQueryにコピーする際、一旦Apache Avro形式に変換をしているそうでした。 Avroに変換してからBigQueryにインポートすることによって高速化されるようです。
海外のBigQuery導入事例を聞くとデータ量が本当に桁違いで驚愕することが多かったです。 発表のタイトルにもあるPB（ペタバイト）という単語が発表中に頻繁に飛び交っていました。 BigQueryは大量のデータに対してもスケールするという宣伝文句はよく目にしますが、具体的な数値を見るとBigQueryにDWHを構築する時の安心感が増します。
How to Do Predictive Analytics in BigQuery
BigQueryの新機能であるBigQuery MLに関する発表でした。
BigQueryに格納されているデータに対して機械学習でモデルを構築できるそうです。 データ分析を行う人にとっていつも使い慣れているSQLに似た構文で機械学習を行うことができるようになります。 お手軽に試してみたい人向けの機能としては、ハイパーパラメーターの自動決定やデータを学習用とテスト用に自動的に分けてくれる機能があるそうです。 また、アドバンストな機能として、学習率の設定やデータを学習用とテスト用に分ける時の方法の設定を自分で変更できる機能もあるそうです。 現在は線形回帰と二項ロジスティック回帰のモデルがサポートされているそうですが、使用できるモデルはこれから拡充されるようです。 対象としているユーザー層はAutoMLやCloudML APIを使う層とTensorFlowやCloudML Engineを使う層の中間層らしいです。
発表の後半ではHearst Newspapersさんでの導入事例の紹介がありました。
オンラインで提供している新聞購読サービスの解約予測モデルの構築をBigQuery MLを使って行ったそうです。
利用ログやデモグラ情報などから、そのユーザーが解約するかどうかを二項ロジスティック回帰で予測するモデルだそうです。 このモデルを構築することによって、どの属性がユーザーの解約に寄与するのかを可視化することが出来たそうです。 プロトタイプの構築はわずか1日で行うことができ、本番投入もわずか2スプリントで行うことができたそうです。
BigQueryにすべてのログやマスタデータが集約されている環境では非常にパワフルな機能であると感じました。 大量のデータに対する機械学習をシンプルなSQL記法で行うことができるため、アナリストが自分で予測モデルをつくることの敷居が下がるかと思います。 まだモデルの種類は2種類しかありませんが、将来的に増えていくことを強く期待しています。
A Modern Data Pipeline in Action
モダンなデータパイプラインを構築するためのパターンの紹介でした。 なお、データパイプラインとはデータに対して以下の一連の処理を行うためのシステムのことです。
Ingest → Transform → Store → Analyze → Visualize
発表中では以下のパターンが紹介されていました。
一度取得したデータに対して、再度処理をかける時のパターン
プログラムのバグやビジネスロジックの変更に備えるためのパターンです。 PubSubからのデータをDataFlowでBigQueryに入れるための流れとは別に、GCSにAvro形式でデータを保存する流れを作ります。 もしもの時にはこのデータをDataFlowで再度処理してBigQueryに入れ直すことができます。
データのバックフィルをする時のパターン
CloudComposer(マネージドAirflow)を使い過去分のデータをBigQueryに入れるのがベストプラクティスらしいです。
また、データパイプラインのアーキテクチャを考える上で重要なことも紹介されていました。
Decoupling
DBやログストリームなどのデータを生成する部分をデータを消費する部分をPubSubを使って分離させる。
Simple, Elastic, low-cost
マネージドサービスの活用によって、スケーリングとロードバランスに関する問題を考えなくても良いようにする。
Low Latency
ETL処理の負荷を可能な限り小さくして、低レイテンシでBigQueryにデータを入れる。
Stream and Batch
DataFlowを使うとストリーム処理、バッチ処理の両方を同一のソースコードで処理可能になる。
Easy re-processing
DataFlowによる変換処理前のデータをGCSに保存することによって、容易に再処理をできるようにする。
High-Level
DataFlowならば簡単な記述で大きな処理を行わせることができる。
Portability
DataFlowはApache Beamでプログラミングできるため、ロックインされない。
バッチ処理とストリーム処理を同じソースコードで実現できることにDataFlowの実力を感じました。 現在DigdagとEmbulkを活用してETLを構築していますが、CloudComposerやDataFlowを使用したパターンとの比較も真面目に検討する必要性を感じました。
Real-Time Stream Analytics with Google Cloud Dataflow: Common Use Cases and Patterns
ストリーミングデータをリアルタイム分析をするためのパターンの紹介でした。
ストリーミングデータの特徴として、途切れることがないこと、予期せぬディレイが発生することなどが紹介されていました。 また、そのためにWindowingやWaterMarkなどのバッチでデータを処理するときには考えなくてもよい概念も紹介されていました。
後半ではCloudDataFlowを使った時の頻出パターンの紹介がなされていました。
Exactly-onceの実現
PubSubはAtLeastOnceの取り出ししかサポートしないために、DataFlow側でExactly-onceを実現するための方法です。 各々のイベントのAttributeにイベントID（乱数）を埋め込み、Dataflow側でwithIdAttributeすることによってExactly-onceが実現されます。
壊れたデータの扱い
PubSubにはリトライ機能があるため、壊れたデータがやってくるとそのデータを無限に処理しようとしてしまいます。 そのため、予期せぬ例外をtry-catchで拾い、それをdead letter用のTopicにpublishすることでこの問題に対処できるそうです。 また、壊れたデータを後から解析するためBigQueryに永続化をしたり、アラートを上げるためのTopicにpublishするなどの派生パターンもあるそうです。
スキーマ変更への対応
イベントにフィールドが追加された時に対処するためのパターンです。 BigQueryのテーブルに対するスキーマ変更はダウンタイムなしで実行できるため、フィールド追加を検知した時にテーブルの列追加を行います。 また、前述したリトライ機能によって、テーブルへの挿入に失敗したイベントの取得もできます。
リアルタイムにデータの非正規化をする
BigTableにもデータを入れ、DataFlow上でそのデータとJOINすることによってリアルタイムでデータの非正規化を行います。 @SetupでBigTableへのコネクションを確立し、@Teardownでコネクションを閉じるようにすると良いそうです。
ストリーミングデータを処理するにあたって、データの到着が遅延するという特性はバッチ処理にはない概念です。 ですが、DataFlowを活用することによって、これらの問題に対処できる可能性も同時に感じました。
Securing Access to GCP resources
VPCの新機能であるVPC Service Controlについての発表でした。 VPCの中にセキュリティ境界を作ることができ、そこに出入りする通信のルールを定めることができるそうです。 GCSバケットに対するアクセスを接続元IPによって制限し、専用線で接続されたオンプレ環境のみからのアクセスに限定するという使用例が紹介されていました。 オペミスによってIAMの設定をミスしてしまった時や、内部の人が悪意を持ってアクセス権を変えてしまった時の防波堤として機能するようです。 たとえIAMでアクセスが許可されていてもVPC Service Controlの設定が優先されるそうです。
この機能はまだアルファ版なので使うためには申請が必要ですが、早くも利用してみたい気持ちが高まります。 データ流出事件のレポートを読んでいると、その原因の多くがアクセス権設定のオペミスであることに驚かされます。 人間は誰しもオペミスをするので、このような仕組みで2重3重に防御することでデータ流出の危険性を低減できるのではと期待できます。
Better Practices for Cloud IAM
Cloud IAMの説明とベストプラクティスの紹介でした。 発表の前半では、Cloud IAMの説明として、以下のようなことが紹介されていました。
- プロジェクトは信頼境界を引くためのもの
- Resourceは階層構造を持っており上位階層の設定は下位階層に引き継がれる
後半では、具体的なベストプラクティスの紹介がされていました。 主に以下のようなことが紹介されていました。
ロールを割り振る対象はユーザーではなく、グループにする
Google Groupで作成したグループに対して権限を割り振ることで新しい人が入った時の運用負荷が下がる。
可能な限り小さな権限を与える
Primitive Roleはプロジェクト全体に対する権限を与えてしまうので、Predefined RoleかCustom Roleかを使うようにする。
追跡するための情報を残す
監査ログをGCSかBigQueryに保存する。
組織の構造をCloudIAMの階層構造に反映させる
組織全体の設定はOrganization Policyで管理し部署ごとの設定はFolderで管理する。 そして、サービス毎、環境（production、development、test）毎にプロジェクトを分ける。
プロジェクトは信頼境界を引くためのものということが目から鱗な発表でした。 今までは開発用のリソースと本番用のリソースを同一プロジェクトに入れていたため、アクセス権の設定に頭を悩ませることが多かったです。 あの時にプロジェクトを分けるという発想に至っていれば…という後悔も同時に感じました。 「とりあえず使って見よう！」という状態では後回しにされがちなIAMの設定を体系的に知ることができ、今後のGCP運用のための大きな知見でした。
感想
Google Cloud Next'18に参加することによって今まで知らなかったGCPの機能を知ることができました。 今まではAWSをメインのクラウドとして使用し、GCPはBigQueryを使うのみであったため、GCP全体を本格的に学習することはありませんでした。 しかし、いざGCPについて学習するとどのサービスもとても奥深く、自分の理解不足を強く実感しました。 また、今回はセッションを聞くことを中心に時間を過ごしましたが、Googleの人と直接話すことができる場にもっとを顔を出せばよかったと感じました。
そして、英語でのコミュニケーション力不足も強く痛感しました。 発表の最中に上手く聞き取れなかった部分を後で字幕付き動画で確認するととても平易な英語なことが分かり、落ち込むことが多かったです。 これからの弊社の大きな目標に海外展開がありますので、英語の継続的な勉強の必要性を実感しました。
まとめ
今回のGoogle Cloud Next'18は会社の出張という形で参加しました。 参加期間はすべて業務扱いとなり、交通費、宿泊費の他、出張手当も会社からサポートされました。 国外のカンファレンスへの参加のサポートはエンジニアとして非常にありがたいことであると感じました。 今回の出張で得た知見を日頃のサービス開発に生かしていきたいと思います。
スタートトゥディテクノロジーズでは、一緒にサービスを作り上げてくれるエンジニアを大募集中です。 ご興味のある方は、以下のリンクからぜひご応募ください！ https://www.wantedly.com/companies/starttoday-tech/projects
