オールアバウトTech Blog

株式会社オールアバウトのエンジニアブログです。

オールアバウトではなぜGCPを選択したか

アドベントカレンダー2017 インフラ GCP

SREGの@takkyです。

この記事は All About Group（株式会社オールアバウト） Advent Calendar 2017 2日目の記事です。

GCPの東京リージョンがオープンされて、約1年経ちました。 オールアバウトでもGCPの東京リージョンオープンに合わせてGCPをメインクラウドとして使い始めました。
この記事ではオールアバウトではなぜ、GCPを選択したか / GCPをどう活用しているかについてお伝えしたいと思います。

前書き

オールアバウトの歴史は長く2001年2月にサービスを開始しました。*1
2001年頃というとオンプレミスやデータセンターで運用するのが当たり前の時代だったかと思います。
そのためオールアバウトは、インフラのほとんどをデータセンターに持つという構成になっていました。
データセンターでは物理マシンは50台以上(これはサーバだけでなくスイッチやルータなどを含む)、仮想サーバは200台以上データセンターで動作しています。
物理マシンを取り扱うため、機器の保守更新やEOSLが問題となってきます。
また、機器に故障があった場合データセンターへ駆けつける必要があるなどインフラエンジニアにとっても負担となっていました。

そのため、クラウドへの本格的な移行が必要となってきました。
どのクラウドに移行するかに関しては2016年の上旬に検討を始め GCPに決定しました。

なぜGCPが選ばれたか

  • コスト面
    サーバのインスタンス料金が他のクラウドサービスに比べてかなり安価であること。 特にGCEにおける継続利用割引*2 などがあったため

  • 台湾リージョンでも日本からのレイテンシが小さい
    クラウドの検討の際にはGCP東京リージョンオープンするかも。という噂があったぐらいですが、台湾リージョンでも一般的なWebサービスであれば十分な速度がでていました。
    また、クラウド移行を考えいていた最初のるサービスが日本国内というよりも海外向けのWebサービスだったため台湾リージョンに構築してみようとなったのも要因の一つです。

  • 将来性への期待
    BigQueryなどの大規模データ処理をする基盤はGCPには整っており、データ処理に関してはGCPに強みがあるだろうとの将来性への期待のため選択しています。
    現にBigQueryやDataflowなどはいまではプロダクト上無くてはならないサービスになっています。

その他にも様々な要因はあるのですが上記の理由でGCPを使うことに決定しました。

GCPを実際に使っていいと感じた所

  • インスタンスのメンテナンスがほぼ不要
    他社クラウドの場合機器のメンテナンス等でインスタンスが停止される場合がありますが、GCEの場合はライブマイグレーションで自動的に別の機器に移行されるのでメンテナンスに関しては特に考える必要がありません。
    ライブマイグレーションが行われたかどうかは、ログを確認しないとわからないぐらい意識しなくて良いです。
    ライブマイグレーションの凄さは以下記事を参考にするといいでしょう。

cloudplatform-jp.googleblog.com

  • Dockerの実行環境が整っている
    KubernetesのマネジメントサービスであるGKE(Google Kubernetes Engine, 最初はGoogle Container Engineという名前でした)やDocker ContainerのレジストリであるGCR(Google Container Registry)などがGCPにあるため、Dockerの実行環境として選定時点では優れていると感じました。
    またGoogle Container Builderなどの周辺サービスの充実も利点の1つです。

  • Google Cloud Shellがよい
    Google Cloud Shellと呼ばれるブラウザからシェルの実行ができるサービスがあります。障害対応時などに有効活用できています。
    また、弊社ではWindowsユーザとMacユーザがいるためハンズオンなどを行う際にはインストールマニュアルを2種用意する必要があったのですが共通した環境が使えるようになった。というのも良かったと感じた点です。

  • ビッグデータ処理基盤
    BigQueryは元よりDataflowやCloud Pub/Subなどビッグデータを処理する基盤が整っているのもGCPの利点です。
    実プロダクトでは以下のような使い方をしています。

allabout-tech.hatenablog.com

  • StackDriver/StackDriverLoggingなどのログ収集基盤
    GCE/GKEの場合google fluentdでログをStackDriverLoggingに転送しておけば集約して見れるのが利点です。また、BigQueryやGCSへのエクスポートなども整っています。 AgentさえいれればStackDriverで各種リソースの監視ができるのもメリットです。

  • 機械学習API
    Google Cloud Vision API(画像分析API)やGoogle Cloud Speech API(音声解析API)などGoogleが培ってきた機械学習モデルを利用できるAPIが提供されているのもメリットです。
    一部サービスのCMSなどで実際に利用が進んでいます。

GCPを使ってちょっと足りないなと感じた所

  • 日本語の情報が少ない
    日本語ドキュメントは翻訳が追いついていないのか英語ドキュメントに比べて不足している部分もあります。とくにそのサービスがGAになった場合でも日本語のマニュアルではBetaのままということがあります。
    対応策として、英語ドキュメントも見る必要があったり、公式サポートを利用したり、GCP User Groupの勉強会に参加して情報を得るなどを行いました。

  • Webサービスを作る上でのマネジメントサービスが少ない
    どうしてもAWSと比較すると、マネジメントサービスが少ないです。例えばAWSのElasticCacheに相当するKVS(Redis)のマネジメントサービスは2017/12/2時点では無いです。
    Cloud Lancherというワンクリックで用意されたOSSをデプロイ出来るソリューションがあるのでそれを使うのも手でしょう。
    また、AWS lambdaに相当するサーバレス実行環境であるGoogle Cloud FunctionsはBETAのためSLA対象がないので本番利用には覚悟がいります。

  • CloudSQLの性能面
    マネジメントサービスなので当たり前なのですが、CloudSQL(MySQLやPostgreSQLのマネジメントサービス)ではMTS(Multi Thread Slave)がonにできなかったりここをチューニングしたいのに...みたいなところがチューニングできなかったりするのが若干不便です。 また、大量にデータを書き込みするとレプリケーションの遅延が起きたりと不便な点が多いです。 Google的にはBQやSpannerを使ってねってことなんでしょうか。

まとめ

この記事ではオールアバウトでなぜGCPを選択したか。そして現在どのように活用しているかについて紹介しました。
GCPではGKEを中心としたコンテナ実行環境周りやStackDriverを中心としたモニタリング・ログ基盤、そしてBigQueryやDataflowを中心としたデータ処理基盤に強みを持つクラウドであると感じました。
それだけでなく、CloudSpannerのような高スケーラビリティ・高可用性・高パフォーマンスを発揮するリレーショナル・データベースやTensorFlowのトレーニングをマネジメン度で実行できるCloud Machine Learning EngineなどGoogleでしかできないサービスもあります。
まだ触ったことは無いのですがいつかは試してみたいですね。

今回はオールアバウトはなぜGCPを選択したか / 1年間使った感想を公開しました。
12/8の記事ではその中でもGKEで1年運用してきたことにフォーカスを当てて紹介したいと思います。

*1:https://corp.allabout.co.jp/corporate/message.html

*2:https://cloud.google.com/compute/docs/sustained-use-discounts?hl=ja