Future Tech Blog
フューチャー技術ブログ
Infrastructureカテゴリ

Google Cloud Next ’19 in Tokyo Day2 セッションレポート

はじめに

こんにちは、TIG DXチーム 1の村田です。Google Cloud Next ’19 in Tokyo Day2 にチームメンバーで参加しましたので参加レポートをお送りします。

チームでの参加に至った理由ですが、社内の中でも特にDXチームではGCPの活用事例が非常に増えており、著しい変化を見せるGCPの最新動向を知ること、またGCPサービスの深い理解すること、他社事例などに刺激を貰うことで、自社のFuture IoTサービス 2をさらに成長させたい、という思いがあったことが背景にあります。

…という建付けで、実際にはチームメンバーの村田さんによる「みんなで行こうよ」発言ですぐに決まりました。

Google Cloud Next ’19 in Tokyoとは

「かつてないクラウドを体験しよう」をテーマに、📍東京プリンスホテル, 📍ザ・プリンス パークタワー東京の2ヶ所で 7/30~8/1の3日間に渡ってクラウドの最新動向や、採用事例を学べるセッションが開催されるカンファレンスです。ハッシュタグは #GoogleNext2019 です
2019年は160ものセッションが開催され年々熱気が増しているように感じます 2。

https://cloud.withgoogle.com/next/tokyo/

会場の様子

当日は気候的に猛暑であったという点で物理的な熱気が凄まじく、会場へ向かうだけでかなり試されました。2ヶ所の会場それぞれでセッションが存在するため、シャトルバスで15minかけて移動するか、徒歩8分程で移動するかの選択肢でした。思念体を構成する一部のメンバーは両会場のセッションを交互に予約したため4往復するハメになり詰んでました。会場を1つにまとめるようなセッションの選び方もイベントを楽しむためには重要かもしれません。

ちなみに、移動途中には増上寺の敷居を通らせていただくのですが、歴史ある寺院の建造物とバックにある東京タワーを一緒に見ることができて、いかにも東京らしい絶景を味わえます。

会場では弊社の代表取締役社長の神宮さんパネルがお出迎え。知らなかったので一同でビビりました。

セッションレポート

まずは、Day2について、私たちが聴講したセッションについて報告します。Day3の午後のセッションもいくつか参加したので、別の記事で公開予定です。

本来は3日間フル参戦したかったのですが、業務調整が大変すぎるという判断でDay1参加は見送っています。全体を期待した方、すいません。

☁基調講演

こちらから講演の様子をオンデマンドで視聴できます。

内容は、様々なGCPを利用しているユーザ企業の方々がビジョンや戦略を中心に説明。統一しているのは、多くの企業も「ユーザーファースト」を謳っており、デジタルシフトがますます進んでいると感じました。技術的には、「BigQuery」や「Cloud Spanner」が多く利用されているようでした。

☁Cloud Code とコンテナツールで Kubernetes を使った開発を徹底効率化

本セッションでは、Cloud Code、skaffold、Tekton などを使って、Kubernetes 開発をどのように効率化するか、デモを中心にご紹介します。Kubernetes は怖くない！
https://cloud.withgoogle.com/next/tokyo/sessions?session=297697-140795

わたしは普段、helmを利用したk8sアプリケーションのデプロイを行っているのですが、コーディング→GCR push→kubectl applyの流れを効率化できる手法を知りたいと思い参加しました。ただし、今回はCI/CDではなくローカル環境での開発をCloud Codeを利用して効率化するという話でした。

k8sを用いたローカル開発の課題

k8sをつかうとコード開発以外に細かい作業がたくさんあります。

  • ソースコードを変更するたびに、YAMLなどの設定の変更を始めとした様々な繰り返し作業が発生
  • ターミナル、ブラウザなど切り替えが多いため、コンテキストスイッチにより生産性が低下
  • 関連ツールを全て覚えるのが困難

Cloud Code for IDEs

  • エンジニアがコードにフォーカスすることを支援してくれるツールで、k8sの開発サイクルに対応し、デバッグ機能・クラスタ管理・テンプレートと編集支援をしてくれる
  • Kubernetesアプリケーションの継続的デプロイメントをサポートするCLIであるSkaffoldを利用している
  • Build push deployを指定して自動化してくれる

Cloud Code for IDEの主な特徴

（1）Kubernetesの開発サイクルを短く
（2）デバッグ
（3）クラスタ管理
（4）テンプレートと編集支援
（5）エコシステムとの統合
（6）GCPとの統合

セッションの感想

Kubernetesは柔軟でスケーラブルではあるが学習コストが高いというのは今身をもって体感しています。ローカルで簡単に試す環境を作りたい、勉強したいという初心者にもかなり使えるツールなのではないかなと感じました。

個人的には帰宅してすぐにVSCodeにCloud Codeプラグインを入れちゃいました。仕事ではそこそこの規模なGKEを運用しており、この場合はhelm等使うことが良いと思いますが、小規模でk8s使って開発したい時に活躍しそうです。

kubectlでのクラスタ切り替えや、gcloudでのクラスタ情報を取得など、多くのコマンドがあり覚えきれないですよね泣。そういった部分が隠蔽化されて、ワンポチでできちゃうってのはすごく使いやすいですね。

☁Cloud Run 〜Knative を使った新しいサーバーレス

本セッションでは Cloud Run を使って具体的にどういったことが出来るのかデモを交えながら説明します。
https://cloud.withgoogle.com/next/tokyo/sessions?session=297911-140799

コンテナアプリケーションのデプロイ先として、Cloud Runを使うか・GKEを使うか、を迷う機会があり、Cloud Runの特徴についてより深く学びたいと考え参加を決めました！ Cloud Run・Knativeについて、サーバーレスとは？ という話題から実際に使うときのプロダクト選定基準まで幅広く解説してくれたセッションでした。

サーバーレスとこれまでの課題

  • サーバーレスとは？
    • No infra management、Fully managed security、Pay only for usage の3点
  • GCPのサーバーレス
    • Functions(Cloud Functions)、Apps(App Engine)、Containers(Cloud Run)
  • これまでの課題
    • 対応言語や対応ライブラリに依存すること、ベンダーロックイン、GPU/TPUなどの特定リソースにアクセスできないことの3点

Knativeが登場

  • k8sクラスタ上にFaaS/PaaS実行環境を構築できる
  • 特徴は、「OSS」「コンテナをサーバーレスライクに使える」「k8sクラスタのHWリソースが使える（GPUなどもOK）」

Cloud Run

  • Cloud Runの主な特徴が3つある
    1. 高速なデプロイと、リクエストがなければコンテナ数は0になる = 課金されない
    2. サーバーレスネイティブ
    3. 高いポータビリティ
  • 2種類のCloud Run実行パターンが有る
    • Cloud Run (以下、無印)と、Cloud Run on GKEがある
  • 2つのCloud Runの違い
    • インフラ面で違いはあるが、「Same API, Same CLI, Same App」である
    • ユーザ目線では、無印はマシンスペックについていじれる項目が少ない。VPCへのアクセスが無印ではまだできず、on GKEは可能という違いがある
  • Cloud Runのリソースモデル
    • 「Service」カスタムドメインも選択可能
    • 「Revision」splittingはApp Engineで既にできるが、Cloud Runでもそのうち可能になる（これは期待！）
    • 「Container Instance」
  • Cloud Runのその他の特徴
    • エンドポイントはインターネットFacing
    • Cloud PubSub、Cloud Tasks、Cloud Schedulerトリガーで起動ができる
  • 高速なデプロイとスケールをセキュアに実現する技術
    • gVisorという、ホストとコンテナの間に入るレイヤーがある

Concurrencyについて

1つのコンテナに投げられるリクエストの最大数。
Concurrencyの設定を変えて、コンテナ数がどのように変化するか見てみました。

  • Concurrency = 1、1400TPSで負荷をかけると、Containerは500個へスケール
  • Concurrency = 80、1400TPSで負荷をかけると、Containerは100個へスケール

Concurrencyの値を大きくした時に注意すべきことは、コールドスタートが少なくなることと、スレッドセーフにする必要がある点です。

GCPのサーバーレスどう使い分けるか？

  • Functionsは「コードベース」で「イベントドリブン」
  • Appsは「コードベース」で「10年の歴史があるので知見が転がっている」
  • Containersは「コンテナベース」「ランタイム制約・ロックインなし」「まだベータ版」
  • 公式の使い分けチャートもあります！

セッションの感想

これからはコンテナベースなサーバーレスが主流になっていくのかなーと感じられるセッションでした！ いまはFunctionsめちゃくちゃ使ってるけど、徐々にCloud Runに移行しようかなと思いました。

あと、Cloud Run東京リージョン来てくれてうれしい！（VPC Accessも期待しています！）

☁データウェアハウスのあるべき姿とBigQueryの新機能

今日、企業はデータを活用するにあたって、
データ ウェアハウスに求められる役割についてあらためて考えます。
https://cloud.withgoogle.com/next/tokyo/sessions?session=D1-3-S01

もともとデータベースを主軸に仕事をしてきたこともあり参加しました。内容としては主にBigQueryの概要と性能アップ、そして新機能の紹介でした。

BigQuery特徴

  • 性能
    • ある事例では25PBの保存データやPBのクエリの実行記録もある
    • 昨年まで400MBのクエリが24.5secで処理されていたが、現在は4.2secで処理された記録がある
  • サーバーレス
    • upgradeやセキュリティアップデートをシームレスに実施できる
    • できるできる自動再クラスタリングがバックグラウンドで実行される
  • Open
    • BigQueryをどのPFでもどのようなインプットからも利用できる

新機能

  • Parquet & ORC Federation Beta
    • Parquet/ORCを使ったBigQueryテーブルが作成できる
    • 列ファイル形式と論理区画により高速に
    • Hiveパーティションで、クエリとロードをサポートしている
  • Cloud Sql Federation Beta
    • BigQuery＋PostgresQL、MySQL、CloudCqlの組み合わせで使う場面が多い
    • External query functionを利用してBigQueryからCloudCqlへクエリを投げることができる。Joinも可能。
  • BigQueryStorage APIs
    • BigQueryからデータを取り出すための新しいAPIです。
    • BigQueryのストレージ層に対してgRPCでクエリを投げることによって、従来のAPIと比較して高速かつリアルタイムにデータを取得できる。
  • BigQueryBI Engine
    • レポートで頻繁に必要とされるデータをインメモリ処理にしてくれることで、パフォーマンスを向上させる
    • BigQueyとBIツールの間にデータを蓄積するメモリを加えることで実現している

セッションの感想

DWHやそれを取り巻くBIの大きな課題である性能問題に注力するだけでなく、RDBとの連携やAPIの提供などユーザがさらに使いやすく他システムと連携できるような機能を提供していますね。

今後のDWHの選定では性能だけでなくどれだけ他システムとの連携が取れるかが大事な軸になりそうと思わせるセッションでした。

☁オブザーバビリティを加速させる Stackdriver

本セッションでは「オブザーバビリティ」とは何かを紹介し、従来の監視との差異、そして Stackdriver がどのようにオブザーバビリティを確保する支えになるかを解説します。
https://cloud.withgoogle.com/next/tokyo/sessions?session=295818-140777

最近DevOpsという単語を意識する機会が多く、GCPにおいてDevOpsを支えるStackdriverについて詳しくなりたいと思い参加しました！ SREにおけるStackdriverの活用方法について、運用におけるフェーズごとに適切なプロダクトとその利用方法を解説してくれるセッションでした

DevOpsとSRE

  • DevOpsからSREへ。SREはDevOpsの実践方法である
  • SREとは、意思決定にデータを用い、人間の主観で判断しない。また、運用の課題(スケーラビリティ、信頼性、効率)をソフトウェア・エンジニアリングで解決する
  • オブザーバビリティ（可観測性）とは、システムを運用する上で判断に必要な情報が取得可能な状態であること

SREにおけるStackdriverについて

各運用プロセスで必要なデータは異なります。

  • 通常運用
    • 全体感のわかる統計データを取得
    • SLO違反が発生した際にアラートが飛ぶよう設定する
    • Istioを使ってるのであれば、Cloud Service Meshも有益
  • 高負荷時・調査
    • パフォーマンスモニタリングにはAPMなど専用のメトリクスが容易されているのでそれらを活用する
    • Stackdriver Profiler
    • Stackdriver Trace
  • その他障害対応
    • Stackdriver Error Reporting

セッションの感想

アプリのパフォーマンス検証において有用なサービスを知ることができたので、プロジェクトでもどしどし使っていきたいなと思いました。あと、IstioはStackdriverへの詳細メトリクス連携を目的としたモニタリングの観点のみだけだとしてもぜひ導入したいと思います。

☁デモで魅せます！ GCP で生産ラインにおける検査工程の効率化

GCP のデータ関連サービスを利用したスピード開発により、
生産ラインにおける製品の品質チェックを、どのように実現するか解説します。
https://cloud.withgoogle.com/next/tokyo/sessions?session=D1-8-OS2

7月から工場系の案件に携わることになったため参加しました。工場の品質管理という課題をGCPでデータ分析や機械学習を用いて解決する方法について、デモを交え解説していました。

製造業の課題

  • 製造業では人不足が深刻になっている
  • 人不足のため品質管理に注力したくてもできていない
  • 欠陥品が見つかっても何が原因であるかを分析することに時間がかかる
  • ラインセンサーを使用してもその場限りのデータになっていて、分析目的に利用できていない

どのようにデータを分析すべきか

  • 欠陥品ができた時の工場各センサーのデータをもとに原因分析する
  • 例1
    • 事象：欠陥品が出た時に振動センサーが異常値を示していた
    • 原因：地震が発生していた
  • 例2
    • 事象：欠陥品がでたときに温度変化の線サーバ異常値を示していた
    • 原因：電気線がショートしていた

GCPが提供する欠陥品の発見方法

  • Auto メーリングリストを使って画像認識で欠陥を発見
    • Googleの学習済みモデルを活用
    • すべての開発者が使用可能
    • フルカスタムモデルよりトレーニングデータ量、トレーニング時間、リソースを削減することが可能
    • クラウドでもオンプレでもモデル活用が可能

GCPが提供する大量データ収集、分析

  • ペタバイトスケールのフルマネージドサービス
  • SQL 2011またはJDBC対応
  • BigQueryMLで機械学習モデル作成が簡単に実現可能
  • 位置情報のサポート
  • Json形式、ネストされたデータの対応

デモ

  • 小さなベルトコンベアと車のラジコンを使って工場のラインを再現
  • 部品(車体)に傷がついたという想定でマジックで線を書き、画像認識で検知

☁Transform your work culture テクノロジーが可能にするイノベーションと Diversity & Inclusion

Google re:work の実践的なプログラムをもとに、どのようにテクノロジーで働き方を変え、
Diversity & Inclusion を実現する具体的なヒントをご紹介していきます
https://cloud.withgoogle.com/next/tokyo/sessions?session=D1-6-OS2

働き方改革に興味があったため参加させていただきました。

働き方改革の導入手法としての鍵

  1. Anywhere（在宅勤務）
  2. Simply（業務効率化）
  3. Shorter（退社時間の計画）

Anywhere

実現のためには、まずテーマを1つに定め、モデル部署を選択し、期間を1ヶ月などと定め、トライアルをすることが重要だそう。効果は事後アンケートで効果測定するのが良いとのことです。まずは1回で良いので実施してみると効果が見えるそうです。

Simply

主に会議の効率化について説明されていました。グラウンドルール と呼ばれるシンプルなルールを徹底し、会議時間を短縮、参加メンバーを厳選することが良いとのことです。

  • 最初にアジェンダを会議前に上げる
  • 議事録をみんなで会議中に作る
  • 会議中に次のTODO、決定事項が決まっている

Shorter

個人的に興味深かったのですが、いわゆるノー残業デーにするのではなく、個々人で自分が帰る時間を宣言するモデルが有効だそうです。この「自分」で「自分の勤務時間」を「決める」ということの方が、一斉なノー残業デーより効果があったそうです。結果として、平均勤務時間が8-9h –> 7-8h に減ったとのこと。

全体を通して特に記憶に残ったこと

  • Woman Willに、Playbookがあるのでご参考に。調査結果もここに記載されている
  • トップダウンだけではなく、ボトムアップの動きも重要。トライアルなど実施の前にメンバーへのヒアリングをすること。納得しないと人間は動かない、変わらない
  • 「育児・介護」など事情がある人だけのものではなく、みんなのもの

とても参考になりました。スピーカーの山本 裕介さん、ありがとうございました！

☁Google Kubernetes Engine によるコンテナ セキュリティの道

このセッションでは Binary Auth、Container Analysis、GKE Sandbox など、GKE のコンテナ セキュリティの機能を紹介します。
https://cloud.withgoogle.com/next/tokyo/sessions?session=320063-141088

DXチームは日頃からGKEをバリバリ使っているので、GKE×セキュリティ、を考えようと参加しました。コンテナのリリースフローに合わせて、各フェーズで利用すべきセキュリティサービスを紹介してくれるセッションでした

コンテナの導入による新しいセキュリティの課題

  • アプリリリースの手順をおさらい
    • コンテナ導入前は、「ほとんどが手動」で「サーバに直接モジュールをデプロイ」
    • アプリは1つのマシン上に置かれて動いているので、他のシステムアプリケーションやOSへもアクセスできてしまう
  • セキュリティ上の課題
    • k8sへのアクセス権限の管理が煩雑
    • より複雑なFW設定やネットワークポリシー

コンテナによる新しいセキュリティの可能性

  • 統一したモニタリング
    • コンテナに不正侵入されてないか
  • イメージスキャン
    • 脆弱性のあるモジュールを含んでいないか
  • イメージ署名
    • 署名済みイメージから変更はないか
  • サービスメッシュ
    • コンテナ間のアクセス権限は正しいか、不正アクセスはないか

CI/CD・ビルド

  • GCR: Container Analysis
    • 検出した脆弱性の内容と重要度を表示
  • GKE: Binary Authorization
    • 信頼できるコンテナのみをGKEにデプロイ
    • 信頼チェック済みのイメージと異なるイメージがデプロイされようとすることを防ぐ

アプリケーション運用

  • GKE Sandbox
    • GKEコンテナのセキュリティを更に強化
    • 他人の書いたコードを自分の環境で実行するとして、信頼性のチェックは必要
    • パフォーマンスをすこし落としてでもセキュリティを高める思想
  • gVisor
    • ホストとコンテナ間に1枚かますことで脅威の影響範囲を狭めセキュアに保つ
  • Event Threat Detection
    • GCP環境に存在する脅威を検出
    • クラウドベースの脅威を迅速に検出

ユーザ管理

  • Cloud Identity & Access Management
    • きめ細かいアクセス制御
  • Cloud Security Command Center
    • 複数PJの包括的な脅威検出情報を一元管理できる

セッションの感想

以前参加したGoogle Kubernetes Dayでも、GCPはセキュリティ的にむしろ安全である、という主張がありましたが、まさにそれが体現されていることを実サービスの紹介によって理解できました！
ただやはりコンテナのランタイムポリシーチェックなどをしてくれるGCPサービスはまだ登場してこないですね…(あるいはコンテナランタイムチェックは必要ない、というGCPからのメッセージなのだろうか)

☁TwitterでのGCP事例

Twitter のデータアーキテクチャを、GCP に焦点を当てて解説します。
https://cloud.withgoogle.com/next/tokyo/sessions?session=D1-4-S08

Twitter好きなので参加しました。このセッションのハッシュタグは #GoogleNext19Twitter だそうです。

Twitterの規模

とても大きいということが数値ベースで実感としてよくわかりました。

  • 2013年天空の城ラピュタで “14万TPS”のツイート。50万コア、12万ノード、1日平均5億ツイート
  • Webページにembedされていたりするので、1日1兆を超えるメッセージが飛ぶ

オンプレミスからGCPへの移行

Partly Cloudy というPJ名が指す通り、まずはHadoopクラスタから段階的なクラウドリフトをしたそうです。

  • Twitterにとって戦略的な決断で、Googleであればずっと一緒に成長し続けられると信じた
  • GCP移行でHadoopのクラスタの、ストレージとコンピュートを分離できた
  • オンプレミスとGCPの接続のため、1.6Tbpsのネットワーク帯域幅が必要！
  • クラスタの規模をどうするか。10ノードだと細かすぎるし、1000ノードだと大きすぎる
  • cloud.google.com/twitter にも移行について記載しているよ

セッションの感想

システム規模が私にとって異次元過ぎてクラクラしちゃいましたが、この規模のクラウドマイグレーションを成功させることができたということは、素晴らしい事例だと感じました。

☁Google Cloud Platform でゲノム解析

GCP上で、GATK や DeepVariant、ワークフローエンジン などのオープンソースを使用し、ゲノムデータをエンドツーエンドで解析する方法を学びます
https://cloud.withgoogle.com/next/tokyo/my-schedule?session=D1-5-S03

畑違いなのですが、好奇心を刺激され参加させていただきました。

公開データセット

バイオメディカルリサーチのためのゲノム関連の公開データセットがあります。

  • 未アノテーション系（1000人ゲノムなど）
  • アノテーション済みの（CinVarアノテーションなど）

ゲノム解析の手法

  1. 一時解析（サンプル、シーケンサ、生データ）
    • 物理的な解析
  2. 二次解析（FASTQ, BAM, VCF）
    • Pipelines APIを用いて業界標準のツールやフレームワークを利用可能
    • GATK, dsub/SAMtools, DeepVariant, NextflowをCloudShellから簡単に実行していました
  3. 三次解析（解釈、アノテーション）
    • アノテーション処理はBigQuery, Dataprep, AI Platform Notebooksがオススメ
    • Variant TransformsをGCP上で動かせば、 8000万行というそこそこ大きなデータ量も、並列処理を行うことで2hで完了できる
    • BigQueryを用いたTi/Tv比（ゲノムの品質を見るための指標らしい）のクエリでは、1万人サンプルだと、23TB、行数が3.6億レコードになるが、BigQueryだと1SQLで計算できる。チューニングしなくても8minほどで終わるが、さらにクラスタ化と不要データを削除することで、1min以内に処理が完了
    • DataprocはSpark/Hadoopのマネージドサービスだが、ゲノム解析ツールのHailも実行可能
    • ParabricksでGPUを用いたディープバリアントでき、マーケットプレースから簡単に実行可能

セッションの感想

ゲノム領域は文字通り何も知識がありませんでしたが、単語レベルで知らないことばかりで楽しかったです。
ゲノム解析の仕事をしている人は？ という質問で手を上げた人が少なかったので、日本でこの領域を攻めると先駆者になれそうだと思いました。

☁マイクロサービス、サービスメッシュ（Istio）導入により迅速な開発を実現

マイクロサービス、サービスメッシュ（Istio）導入により、開発、運用の方法が変わります。
このセッションでは、アプリケーション開発の効率を高めるために Istio がどのように既存のネットワークやセキュリティを変えるかについて解説します。
https://cloud.withgoogle.com/next/tokyo/my-schedule?session=D1-6-S11

Istioの機能説明というよりは、なぜそれが必要になったかといった背景などを詳しく説明していただけました。サービスメッシュという考えをより深く理解できると思います。

サービスメッシュの背景

  • MicroServiceが犠牲にしている部分に、オペレーションの負荷増大がある
    • Service as a Serviceを実現するために、サービスのオペレーション部分を同じ形式にする
  • よくあるシステムの課題として「脆弱である」・「透明性の低い」・「成長への足かせになる」といったことがある
    • IPベースのFirewallルールはどのシステムがどのシステムにアクセスしているか分からない
    • 複数のシステムを経由する時に本当の送信元が分からない
    • サービスの追加に、NW（Firewall）、認証、認可、モニタリングが追加で時間がかかる
  • k8sを使っているからと言って解決されない領域
    • 通信時の暗号化が義務付けられていますか？ 鍵変更の頻度は？
  • これからは、サービスメッシュ
    • これを管理するためのもの、全てのサービスを同じにする、認証、認可、モニタリングも同じにする
    • 透明性が高く、言語非依存、柔軟かつ簡単にNW機能を自動化する仕組み

サービスメッシュの効果

  • 観測性やアジリティが高くなる。ゴールデンシグナル（全サービス共通的なエラーレート、レイテンシ、APIコール数などの指標）が見れる。ロールアウト時に徐々に新サービスにリクエストを転送し、エラーバジェットを使い潰さないようにする
  • サービスメッシュの重要な点は、統一性の獲得 できること
  • アプリケーションからインフラから切り離すことができる。例えば、リトライのロジックを書く時、アプリ開発者はインフラのコードを書くことが無くなる。リトライ回数、バックオフ、ジッター追加などの運用が、サービスメッシュにしておけば操作できる
  • k8sを導入していてもほとんどのサービスVM上で動いているのでは？ VMにサービスメッシュを入れて、k8sにサービスメッシュを入れて、通信させることで柔軟性が増し、モダナイゼーションを迅速に行える

セッションの感想

Kubernetesを導入するだけでは解決しない点は、「確かに..」と納得でした。
既存のVMにサービスメッシュを導入しモダナイゼーションへ繋げる点は興味深いと思いました。

☁GCP で稼働する Go アプリケーションのパフォーマンスチューニング

このセッションではレイテンシに問題がある Go 言語のアプリを例にあげて、App Engine と Kubernetes Engine といったクラウドコンポーネントを最適化していく手法を詳細にご紹介します
https://cloud.withgoogle.com/next/tokyo/my-schedule?session=D1-7-S03

最適化の中でも、レイテンシ（応答性能）を小さくすることにフォーカスするセッションでした。
「機械より人間の時間のほうが大事だからね」というイケメン発言が素敵でした。

計測

  • 「計測」は 直感に反する！
  • Goのコードは通常はサーバコンポーネントなので、その部分だけ高速化しても効果薄の場合があるので注意。ユーザーファーストを掲げ、サーバメトリクスだけに依存せず、ブラウザ中のJS、キャッシュ、レンダリングも測定すること。
  • Stackdriverのでウォーターフォールトレースが可能。どのようなAPIコールをどのような順番で出力されるのか。シーケンシャルか、コンカレントかが分かる

改善

  • RDBが支配的な場合インデックスを貼るなどで対応しよう
  • サービスがバッチコールを受け入れる場合ば、NWレイテンシや認証が短縮できるのでバッチ実行しよう
  • 関連しないやつはコンカレントに実行しよう
  • メールの送信を、CloudTaskを用いて非同期化しよう

Go Tooling

  • 性能計測はベンチマークのテストコードを書き、 go test -bench=. で取得できる
  • 逐次処理のトレースは、go test -bench=. -trace a.trace と go tool trace --http :6060 a.trace で可視化できる
  • CPUプロファイリングは、比較的ランタイム負荷が小さい処理で、実行中のgorutineのコールトレースを収集する。go test -bench=. -cpuprofile a.prof やgo tool pprof -http :6060 a.prof

セッションの感想

ユーザファーストという言葉は何度強調しても足りない！ とか、ボトルネックになっていない箇所を最適化しようとするのは自転車置き場議論だ！ といったWordがとても面白かったセッションでした。また、go toolを活用して解析した結果、ボトルネックが標準ライブラリにあるという事がわかり、だったら出力のバッファリングをあえてなくしたほうがユーザ体験が良くなるよといった流れが、実に直感に反した最適化で学びでした。

まとめ

前回のGoogle Next in Tokyoにも増してKubernetesとそのエコシステムについてのセッションが増えてきたように思います。Kubernetes, Istio, Knativeなどデファクトスタンダートになりつつある、これらOSS群をフルマネージドで利用できる環境を整えるんだ、というクラウドプラットフォーマーとしての強い意志を感じました。

ちょうどDXチーム内でもKubernetesについて持ち回りで5分話す会というのを先月から始めたのですが、直近学んだことがセッションの中でも多数登場し、予習復習の意を含めとても有意義なイベントなったのは非常に良い収穫でした。

今後は9/3に開催されるGoogle Kubernetes Dayが控えており、これからの動向がより一層楽しみです！

ぜひDXユニットに興味を持っていただけたら、 Qiita Jobsやこのあたりの職種 もご覧いただけると幸いです。

  1. 1.Technology Innovation Groupの略で、フューチャーの中でも特にIT技術に特化した部隊です。その中でもDXチームは特にデジタルトランスフォーメーションに関わる仕事を推進していくチームです。 ↩
  2. 2.https://future-architect.github.io/articles/20190723/ あたりを参考ください ↩