GCPのCloud Buildサービスの紹介

概要

数か月前にGoogle Home の Action を開発していました。

GCP の Cloud Function を使用していましたが

コードを修正するたびに、Cloud Functionの管理画面から

デプロイをするのが面倒でした。

CI/CD ツールを探していたところ、7月にGCPがCloud Buildを発表していましたので

実際に使ってみました。

 

Cloud Buildとは

GCP上でコンテナのビルドを実行するサービスです。

GCPのフルマネージドサービスとして提供されており、

一日あたり120時間まで無料で利用可能です。

 

コードのコミットをトリガーにし、ビルドが実行されます。

コンテナのビルドだけでなく、単体・結合テストの実行も可能です。

またビルドしたコンテナをGKE、GAE、Cloud Function といったGCPのサービスにデプロイすることが可能です。

 

コードのコミット先としてはGCPのサービスである Cloud Sourse Repository だけでなく、GitHub や Bitbucketなどからもビルドを実行することが可能です。

 

結果

私のGoogle HomeのActionは外部公開していないので、可用性などは無視しました。

Cloud Sourse Repositoryにコードをコミットするようにして、

Cloud Buildを実行し、 Cloud Functionにデプロイするようにしています。

 

実際にサービスで利用する場合は、テスト実行や、ローカルのビルド環境で実行してからコミットなどの仕組みが必要ですが、それらも提供されています。

 

GCP上にデプロイするアプリを開発されている場合、一度使ってみてください。

 

 

 

 

Stackdriver Loggingの特徴と利用方法

昨日 Google Cloud Next ’18 in Tokyoに参加してきました

時間の関係でいくつかのセッションしか聞けませんでしたが、

特に印象に残ったStackdriver Loggingについて書きます。

 

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

株式会社エウレカのSREエンジニアの方の登壇で

Stackdriver Logging の特徴紹介と業務での取り組みについてのお話でした。

cloud.withgoogle.com

社内での取り組みや、利用方法に感銘を受けたので記録のためまとめます。

 

Stackdriver Loggingとは

Google Cloud Platform (以下GCP)で提供されている。ログの収集、閲覧サービスです。

オープンソースのログ収集ソフトfluentdをベースに実装されており

ユーザは基本無料で利用が可能です。

 

Stackdriver Loggingの特徴

GCP内からの自動ログ転送

GCPの各サービスで発生したログが自動格納されていきます。

Kubernetesのデプロイログや、CloudFunctionの実行ログが自動で保存されます。

CloudFunctionの開発時にconsole.logを吐くと、Stackdriver Loggingに記録されます。

 

GCP以外からのログ転送

GCP以外からもログ転送可能です。

google-fluentd というGitで公開されているfluentdエージェントを利用すると

ほかのクラウドベンダ（AWSなど）や自社サーバからログの保存が可能です。

 

GCPの他のサービスへのエクスポート機能

  • Stackdriver Monitoring と連携してアラート上げることができます。
  • GCSに過去ログを保存でき、Stackdriver Logging管理画面で閲覧可能です。
  • BigQueryへのエクスポート （ログデータの分析ができるようになる）
  • Pub/Sub 連携（エラーログをPub/SubにおくってCloudFunctionで処理できる）

 

実際の利用方法

絞り込みリンクの共有

Stackdriver Loggingは絞り込みリンクの作成が可能です。

よく使うリンクは社内共有し、いつでも見れるようにしているそうです。

チャットボットにリンク集出力機能を実装し、

見たいときにチャット経由でリンク集を見れるようにされていました 。

 

エラーログの整理と削減

発生したログをチャットツールに投げるようにし、即対応できるようになっている。

エラーログの発生 ＝ 対応必要となるように

ログ出力の閾値を下げたり、削減を行っているそうです。

（すべてのログが通知されると、どれがクリティカルかわからなくなりますからね。）

 

パフォーマンス観測会

SREチームとサーバサイドチーム合同で開催されるそうです。

BigQueryに送ったStackdriver Logging のデータを CloudDatalab で解析するそうです。

JupyterNoteBookでデータ分析方法の手順書のようなものを作成されていて

NoteBookのコマンドを実行すれば

だれでも、分析データの生成が可能なようになっているそうです。

JupyterNoteBook をGITにコミットすると自動敵にHTML化され

あとから確認可能な議事録替わりになっているとの話でした。

 

感想

データ分析を積極的におこなって、継続的な改善サイクルを回しているのは

エンジニアとしては楽しそうでうらやましいです。

パフォーマンス観測会やJupyterNoteBookでのレポート作成は自社でもやってみたいという半面、サーバサイドと開発が分かれているような従来のスタイルでは実現は難しいと感じました。

（パフォーマンス観測会をやっても、タスクなすりつけあいになりそう…）

SREチームが正しく稼働するには、開発者が責任をもって運用を行う環境や体制が必要だと改めて感じました。