Google Cloud Next '18 in Tokyo 参加レポート

Google Cloud Next '18 in Tokyo 参加レポート

はじめまして。Gincoのサーバ、インフラ全般を担当している鷲見(@soichisumi)です。

先日、2018年9月19日、20日に東京で開催された Google Cloud Next '18 に参加してきました。 Google Cloud Next は、GCP や Firebase の新機能や企業での導入事例の紹介が行われるイベントです。

本記事では、今回のカンファレンスで興味深かったセッションや、同日の夜に行われた Google エンジニアへの質疑イベント Dogrun について紹介します。

Google の発表については動画も公開されているのでそのリンクも載せておきます。

Google Cloud Next '18 in Tokyo セッション

徹底解説 Google Cloud Platform の Serverless サービス

Cloud functions は、ルーティングやスケーリングを気にせず、シンプルに API を記述できるサービスです。 しかし、Cloud functions を使っていると、時折レスポンスに時間がかかる問題に直面します。 リクエストを受け取った時に、Cloud functions で何が起こるのかを知っておくことでこの問題の対策を行うことができます。

この発表では、

  • Cloud Functions は 1 リクエストに対し 1 インスタンスで処理する
  • リクエストを受け取ったとき、空いているインスタンスがなければ新しいインスタンスを作成し、リクエストを処理する
  • しばらく使われていないインスタンスがあれば、そのインスタンスは削除される
  • 新しくインスタンスが立ち上がる際のリクエストの処理には時間がかかる。これを Cold start 問題と呼ぶ (下図参照)
  • Cold start は回避できない
  • 対応策として、前処理の廃止、必要になった段階でのモジュールの読み込み、ローカルキャッシュがある

ことが解説されていました。

image

Ginco では開発初期から procuction で Cloud functions を利用しており、上述の対策などを実践しています。

また記事にして紹介できればと思います。

動画

マイクロサービスのためのサービスメッシュ "Istio" を本番環境で利用するには？

モノリシックなサービスは、コードベースが大きいために開発が遅くなりやすく、些細な変更の反映にもサービス全体を再デプロイする必要があるため、変更のリスクが高まります。

これらを別々のサービスとして分けることで、開発者は個々のビジネスロジックのみに集中することができます。また、サービスごとにデプロイすることができるため変更のリスクが少なく、機能ごとに適切な言語や技術を採用しやすくなります。これがマイクロサービスです。

しかしマイクロサービスは、サービスが多い分、不具合が発生した場合の原因究明や、サービス間のセキュリティの確保に手間がかかります。

その問題の解決を目的としているのがサービスメッシュであり、その実装がIstioです。

サービスメッシュでは、すべてのマイクロサービスにproxyを追加し、サービス間の通信をすべてproxy経由で行うことで下記を可能にします。

  • サービスを跨いだメトリクスの収集
  • サービスの接続関係の可視化
  • 負荷分散
  • サービス間のセキュリティの確保

{{< figure src="/img/istio-architecture.png" class="center" title="Istio architecture" width="520" height="688" >}}

Istio は一部だけでも導入が可能で、サービス稼働状況の監視のみに使うことも、ロードバランス機能のみを取り入れることもできます。 段階的な導入が推奨されていました。

動画

Stackdriver Logging と周辺サービスを使用したシステムモニタリング

エウレカさんによる、エウレカでどのようにロギング及びパフォーマンスモニタリングを行っているかという話です。

ログのフィルタリング、Stackdriver Monitoring との連携によるメトリクスの監視だけでなく、ログをエクスポートして分析していた事が印象的でした。

Stackdriver には様々な形式でログを出力する機能があり、Cloud Storage, Big Query, Cloud Pub/Sub へエクスポートできます。

エウレカではログを Big Query へエクスポートし、Cloud Datalab によりレポートを作成し、SRE チームとサーバサイドの開発チームで定期的にパフォーマンス観測会を行っていました。パフォーマンス観測会ではSLIだけでなく、req/sec 、レイテンシとそのヒストグラム、先月比をメトリクスに振り返りを行っていました。

SLI は、まずSRE の活動を取り入れることを重視したため、リクエストに対するステータスコードの割合としているそうです。

GCPを利用してスケーラブルなCIサービスを作った話

Rocro さんによる、Rocro を GCP でどのように開発したかについての話です。

Rocro は自動コードレビュー、API ドキュメント作成、負荷試験サービスです。Rocro の自動コードレビュー、負荷試験サービスはGinco でも利用しており、サービスの改善に役立っています。

発表では、主にCloudBuild を用いて、ビルド時間を6時間から20分に削減した際に得られたtips が共有されました。

為になったtips としては

  • CloudBuild はビルドスクリプトの検証をローカルで行うことができて便利
    • 他のCIサービスでは実際にgit pushして試す必要がある
  • CloudBuild はマシンタイプが選べ、ビルドから更に並列ビルドのリクエストを発行する事により、リソースが許す限り並列化できる (同一インスタンスなので料金は変わらない)
  • gsutil cpを使うときはmオプションを指定して並列化
  • K8sでリソースの利用効率を高めたい場合、同時にリソースを使わない複数のPod をまとめて、それらの中の最大のresources をまとめたPodに設定する
    • こうすると最大のresources のpod以外のリソースが浮く

がありました。

Ginco のサーバサイドの開発では、CircleCI を利用しており、現状特に不満はないですが(GitHub やSlack との連携やGUI 、ビルドキャッシュは CircleCI のほうが簡単に行えます)、重いビルドを頻繁に回す必要が出てきた場合には CloudBuild を検討すると良いかもしれません。

Dogrun 2018 @ Google Cloud Next '18 Tokyo

1日目の夜には GCP の Product Manager (以下PM)や Developer Advocate (≒エヴァンジェリスト. 以下DA)の方々に来て頂き、質疑応答が行われました。

僕は Serverless Room に参加しました。

Serverless Room では、Firebase / Cloud functions について、Firebase / Serverless の PM / DA の Mike McDonald, Bret McGowen, Stewart Reichling, Brian Dorsey との質疑応答が行われました。

image

興味深かった話としては、

  • VPC networking で Cloud Functions から様々なマネージドサービスが利用できるようになる(Memorystoreとか)。 年明け辺りアルファ公開予定。
  • Serverless Container も年明け辺りに出る。言語に縛られず function を書けるようになる
  • 複数リージョンの Cloud Functions を叩き分けたい場合、Cloud Load Balancing の endpoint として今後登録できるようにするのでそれを使うと良い
  • Cloud functions からのリクエストであることを確認したい場合、Cloud functions identity というアルファ版の機能が今後提供されるのでそれを利用するといい

がありました。

特に VPC networking と Serverless Container は良いですね。Serverless でできることが増え、ランタイムの変更でオーバーヘッドが削減できます。

他にも様々な進行中のプロジェクトについて知ることができ、Serverless への期待が高まりました。

まとめ

Cloud next '18 の基調講演やセッション全体から、Serverless は注力していくテーマであり、Kubernetes をベースとして、インフラを気にすることなくアプリケーションが開発できる環境を実現していくという強いメッセージを感じました。

こういった開発者向けの大きなカンファレンスに参加するのは初めてでしたが、カンファレンスではサービス提供側の意図を知れるのが良い点でした。ドキュメントでは、新しいサービスで何ができるかしか分かりませんが、直接会話するとなぜ必要だと考えているのか、今後どうしていくのかが把握しやすく、すぐに利用イメージを持つことができました。

得られた知見は今後の開発に役立てて行き、新しく分かったことがあればまた共有したいと思います。