インフラ未経験エンジニアがGCPで爆速構築する奮闘記

こんにちは、株式会社カミナシのエンジニア @imu です。

はじめに

私はインフラに対して苦手意識（詳しく知らない）があり、issueに対して率先して改善しようとしませんでした。このまま深く触ることはないかなと思っていた矢先、新規プロダクトのインフラ構築をお願いされました。

めちゃくちゃ不安しかなかったのですが、最初から構築する機会なんて滅多にないのでチャレンジすることに！
（内心はやりたくないなと思ったけど…）

私自身は知らない領域にチャレンジすることは好きなので、楽しんでやろうと思いました。 苦手意識がある私がどのように、リリースできる環境を構築したか共有できればと思います！

注意）本内容はα版という位置づけで構築しており、正式リリース時には都度変更をしていきます。

Day 1（技術選定）

弊社はカミナシレポートというサービスを提供しています。このプロダクトはAWSを利用しており、その構成を真似て構築するの予定でしたが、インフラが苦手な私にとっては若干ハードルが高いです。ましてや一人でやるとなれば尚更ですよ…。

kaminashi.jp

となれば、イチから構築するなら別サービスを検討しても良いと思い、ちょうどその頃、社内でデータ基盤をGCP側に構築する話が上がっていたので、新規プロダクトはGCPに構築しようと思いました。
GCP経験者は社内にいませんでしたが、弊社のバリューに「β版マインド」があるのでチャレンジしたいと伝えて、運用が耐えれない場合は別のサービスに乗り換えるという話でGCPを採用しました。（と言うより、自分一人でやるならやってみたい方を採用したかったのが本音）

こういったチャレンジが弊社では出来るのでありがたいです。

Day 2（インフラ構成図）

とはいえ、いきなりGCPのコンソールをいきなり触るのはちょっとハードル高いです。 どういった機能が提供されているか分からないまま進められないのでインフラ構成図を書きました。構成図を書くことで頭の整理にもなるし、誰かに説明するとき楽ですね。

プロダクトに必要な機能から作成したインフラ構成図（α版）です！

インフラ全体はβ版以降まで見据えて書き出しましたが、正直これが正しいのか不安なんですよね…。

社内にGCPのインフラ経験者はいないため、業務委託で関わっていたメンバーに壁打ちをお願いしました！

予め構成図を共有してインフラMTGを開催し、気になる点やアドバイスをいただきました。

• α版までの期間が短かったこともあり、作りすぎずに後から追加できるものは後回しにする
• CI/CDを回せることを意識して、最小構成をを目指す

未経験あるある的なことだと思いますが、いきなり完璧なものを目指してしまったので小さく早く仕組みづくりをすることにしました。 （お恥ずかしながらここは私の反省点）

最終的にα版のインフラ構成図はこちらです！

Day 3-4（Cloud RunとFirebase HostingにDeploy）

Cloud RunにDeploy

基本は公式ドキュメント！
ドキュメントに従ってAPIを有効にしたり、cloudbuild.yamlを最小構成で作成しました。

未経験だといきなりは怖くて、以下の最小構成でまずDeployされるか確かめました。

• Cloud BuildのTriggerを作成
• featureブランチで回るように設定
• ベタ書きで cloudbuild.yaml を作成

cloud.google.com

※Githubの連携は共通アカウントを利用しましょう！個人アカウントだと予期せぬ問題になりますからね

導線が出来た後はBuildã‚„Cloud RunへのDeployã‚’ cloudbuild.yaml に追加してDeployできました。 （APIを有効にしたり権限周りで出来ないことはありましたが…）

FirebaseにDeploy

WebアプリケーションのDeployはFirebaseを利用して、公式ドキュメントを見ました。

cloud.google.com

余裕余裕！と思っていた矢先、Firebase側からプロジェクトが見えないという問題に当たりました。

ドロップダウンリストに追加したプロジェクト名が表示されない！別のプロジェクトは表示されているのに…。

ドキュメント等を探しましたが検討が付かず、他のプロジェクトの差分を見ると怪しい箇所がありました。

結論はGCPで新規プロジェクトを作成するとき、プロジェクト名とプロジェクトIDを同一にしていると表示されないです。

一度プロジェクトを作成するとプロジェクトIDは編集できないため、新規プロジェクトで kaminashi-blog-123とすれば表示されました。

原因が分かったので新しく作り直すことに…。

Day 5（Cloud SQL for MySQLのインスタンス作成）

インスタンスを作成するだけなので、公式ドキュメントを見て最小構成で作成しました。

cloud.google.com

α版のため基本最小構成でインスタンスを作成しています。 CPUやメモリ等は利用者数の増加に伴って、随時変更をしていきます！

GolangでCloud SQL for MySQLに接続するとき、下記ドキュメントを参考にしましたが、接続文字列が //cloudsql になるので注意してください。

cloud.google.com

あとはCloud Buildを再実行してDB接続まで出来ていることを確認しておわりです。

Day 6（Cloud Runのカスタムドメイン設定）

カミナシレポートでAWS Route53を利用していたのでこちらを使います。

公式ドキュメントを見れば困ることはなかったです！ cloud.google.com

HTTPS 接続用のマネージド証明書が自動的に発行、更新されるので便利ですね。こういった細かいことをGCP側がやってくれるので非常に助かってます。
ちなみにマッピングが終わるまでに40分くらい掛かりました。

詰まったポイント

• ググったときに公式ドキュメントじゃなくて個人ブログを参考にすると、内容が古い場合が多かったので公式ドキュメントを見よう！
  • GCPも日々進化しているので公式ドキュメントが一番良いなと思います。可能であれば現役でGCPを触っているエンジニアと壁打ちできると尚良いですね。
• GCPのAPIサービスの有効化、サービスアカウントなどに権限付与は、Try&Errorを繰り返すしかない。
  • Cloud LoggingでCloud Buildのエラーを見るとわかりやすいが、一覧で分からないのが難点。

おわりに

インフラ未経験の私が爆速でインフラ構築出来たのも、業務委託のメンバーと週次で壁打ちや、随時困ったときに相談出来たことが要因だと思います。苦手な私に対してペアプロをしていただいたり、様々な提案をしていただきホントに助かりました。

まずは手動で動く環境を構築するのを優先したため、今ではTerraform化や別の環境を作ったり、私自身がインフラに対する意識も変わりました。 あれこれやってみたい、これはどうすればいいんだろう？などの課題を上げ、解決していくのが楽しくなりました。

とはいえ、まだ正式リリースまでにやることはあります！リリース後も都度改善をしていく必要があるのでチャレンジしがいがありますよ。

また、今のフェーズは領域に縛られない働き方が出来て、カミナシではやってみたいことや実現してみたいことなどが叶いやすい環境だと思っています！

「お、カミナシ気になるなー」と思った方はカジュアルにお話できればなと思いますので、TwitterのDMや下記の採用情報サイトからご連絡お待ちしております！

最後まで読んでいただき、ありがとうございました！ careers.kaminashi.jp