株式会社grasys Cloud Infrastructure エンジニア 佐藤嘉章氏
インフラ専門の技術者集団がいち早くリモートワークに移行した理由
grasysのクラウドインフラストラクチャー部門で顧客向け環境のインフラ設計、構築、運用保守を担当する佐藤嘉章氏。2020年8月にgrasysに入社し、入社後1カ月は新人研修のため毎日出勤していたが、新型コロナ感染症拡大に伴い、研修後は週1日出勤のリモートワークとなった。さらに2020年12月からは完全リモートワークに移行することとなる。grasysはエンジニアのリモートワーク環境構築をどのようにサポートしていったのか。
まずは、grasysの業務内容から紹介しよう。grasysはシステムのコンサルティング、システム開発、インフラの設計、構築、運用保守、ビッグデータなどデータの解析や分析の実施を業務とするインフラ専門の技術者集団だ。
3大クラウドサービスであるGCP、AWS、Azureのほか、システムソリューションを提供するHashiCorp、Elastic、Fastly、Palo Alto Networksともパートナーシップを結び、顧客の要望に応じた最適なソリューションを提供している。運用するシステムに対して累計3億人以上のエンドユーザーがおり、月間のVMインスタンスの運用数が4500台。データ分析基盤レコード数が1日に兆単位の実績を上げている。
今回のコロナ禍に関わらず、インフラエンジニアにとってリモート環境は必須だ。特にgrasysはゲームシステムの構築運用を数多く手がけており、24時間365日のサービスを提供している。
そこで、実はコロナ禍に見舞われる以前からgrasysは月に1日のノー出勤制を実施しており、自宅からの完全なリモートワークに慣れる対策をしていた。
さらに、新型コロナ感染症対策も重なり、2020年1月27日からいち早く社員の90％程度がリモートワークを開始した。感染予防のための外出制限や、買い占めによる食料供給不足対策として、同年2月27日に非常食約7日分を社員全員に配布するといった対応もとられた。
オフィスと自宅の差異を無くす工夫
grasysの社内向け業務サーバーは、物理サーバーを構築するのではなく、全てクラウドで管理するツールを利用している。そのため、オフィスとリモート環境の間で差異はなく、全く同じ環境を利用することが可能となっている。
さらに「より良い自宅の業務環境の構築を目的として、2020年4月20日から各社員に10万円の支給を決定。資産管理の手間を考え、賞与として支給されました」と佐藤氏。自宅環境もオフィス同様に整えるべく、投資を行った。
一方、完全リモートワークにより、社員間のコミュニケーションにはいくつかの問題が発生した。
一つ目は、チームでの業務の進捗管理、特にリーダーが、メンバーの実施している業務の進捗をいかに効率よく管理するかという点。二つ目は、まさに今躓いている問題に対して、迅速に解決に導くためのフォローをどのように行うか。三つ目が、社員それぞれの孤独感をどのように解決していくか。これらが非常に大きな問題として挙がってきたのだ。
そこで、スプレッドシートを用いたKPTを毎日実施することに決めた。KPTとは、現在直面している事柄に対し、Keep、Problem、Tryの3項目に分ける、ふりかえりの手法。それを毎日15分から30分程度、チーム単位で実施することにより、メンバー間のコミュニケーション向上を図った。
インフラ定義ツール「Terraform」を活用し、顧客との環境を構築
続いて、顧客に対する取り組みとして、Cloud Build、TFCを利用した業務環境の共有について紹介された。
grasysでは、顧客とのコミュニケーションはリモートツールを使うことが基本となっており、以下のツールが日常的に使われている。
- 作業依頼や障害連絡 ⇒ Slack、Chatwork
- 定例会議 ⇒ Google Meet、Amazon Chime
- 議事録 ⇒ Google Docs
- 作業証跡 ⇒ Backlog、Jooto
- ナレッジ ⇒ DocBase
また、コミュニケーションツールだけでなく、顧客の業務環境もクラウドを利用して、完全に共有している。例えば、GCPを利用した場合は以下のツールが使われている。
- 業務インフラ ⇒ GKE、GCE
- インフラの構築 ⇒ Terraform、Terraform Cloud
- リソース管理は ⇒ CSR、GCR、GS
- CI/CD環境の実現 ⇒ Cloud Build
顧客に提供する業務環境には、まずインフラの構築が必要となる。業務環境は、開発、テスト、本番など複数の環境を構築する必要があり、同じ構成であることが望ましい。ただし、複数の同じ環境を構築するには、構築手順や必要なパラメータなどを管理することが重要だ。
もしこれが不十分だった場合、構築する担当で異なった構成の環境が作成されてしまう可能性もある。そのため、環境の構築手順やパラメータを一元管理し、管理されたデータをもとに、環境を自動的に構築するツールの導入が望まれる。
HashiCorp社が開発する「Terraform」はこのような環境構築の要望に応える、同一構成のインフラ構築を容易にするインフラ定義ツールだ。また、Terraformで使用するリソース定義ファイルなどをクラウドで管理し、インフラの構築作業を共有できるクラウドサービス「Terraform Cloud」もある。
Terraformには、定義ファイルに構築したいリソース、例えばネットワーク、VM（Virtual Machine）、Kubernetesクラスターなどのパラメータを定義し、インフラ環境を自動的に構築する機能がある。
佐藤氏は、Terraformの基本構成について、リソースの定義ファイル作成や構築に必要なパラメータ、リソース定義、パラメータ設定などの解説を行った。
作成したリソース定義ファイルをTerraformで実行する前に、使用するTerraformのバージョン指定と、リソース作成先であるGCPなどの環境との連携を設定する必要がある。
「TerraformはHashiCorp社にて、逐次機能の追加と改良が行われ、Terraformのバージョンにより、リソース定義ファイルの文法が異なる場合があります。そのため、作成したリソース定義ファイルの文法に適合するTerraformのバージョンを指定する必要があります」（佐藤氏）
Terraformは、以下の3ステップで簡単に実行することができる。
- terraform init ⇒ 初期化およびプラグインなどの取得およびロードを実行
- terraform plan ⇒ リソース定義ファイルや変数定義ファイルなどのチェック、構築されるリソースを確認
- terraform apply ⇒ リソースの構築
このように便利なTerraformだが、ローカル環境で実行されるため、リモート環境下では注意が必要だ。複数人で定義ファイルや実行履歴を管理するには、共用サーバーや共用ストレージを用いるなどTerraform以外のリソースが必要となる。そこで登場するのがTerraform Cloudだ。
Terraform Cloudは、リソース定義ファイルと構築の実行の管理を「Workspace」と呼ばれる単位で管理する。それぞれのWorkspace内に、Version Controlとして、リソース定義ファイルの履歴を管理するリポジトリと、Terraformを自動的に実行するトリガーの設定が可能だ。さらに、Terraformの実行時に、パラメータの変数値として読み込まれる、.tfvarsファイルの指定や、GCPなどのリソース作成先にアクセスする権限の登録も可能となる。
Terraform、Terraform Cloudから実行するメリットの一つは、Terraformの実行履歴の保存が可能なこと。個々の実行履歴には、terraform init、terraform plan、terraform applyの実行ログが保存され、簡単に参照することができる。
また、Terraform Cloudには、.tfstateファイルも用意されているため、リソース先でのリソースの削除も、ワンクリックで簡単に実行することが可能だ。Terraform Cloudの利点をまとめると以下の3つが挙げられる。
- Workspaceにより、各担当者別に構築されたリソースを一括して管理できる
- Terraformの並行実行を容易に管理できる
- Terraformの実行ログや、リソース定義ファイルの履歴管理が容易にできる
Cloud BuildによるCI/CDの実行
Cloud BuildはGCPが提供するCI/CD環境で、多種多様なリポジトリやクラウドストレージからソースコードを取得し、ビルド構成仕様に合わせてビルドすることができる。
「DockerコンテナやJavaアーカイブなどのアーティファクトの自動生成が可能であり、GKEやAppEngine、CloudFunctionといったGCPのインフラ環境や、他のクラウドサービスのインフラ環境への自動デプロイが可能です。以下の図は、私が実際に業務で利用したCloud Buildの構成図になります」（佐藤氏）
佐藤氏は、トリガー起動設定やビルド／デプロイを実行する手順などの説明を行い、Cloud Buildについて以下のように述べた。
「Cloud Build実行時のファイルやスクリプトの一時保存スペースとして、Workspaceが利用可能です。Cloud Buildの実行を起動するためには、リポジトリへのpushなどのトリガーによる自動実行以外に、GCPコンソールからのトリガーの手動実行や、gcloud build submitコマンドでの実行も可能。gcloud build submitコマンドでの実行の場合は、実行の作業エリアがWorkspaceではなく、gcloudコマンドを実行するローカルマシンの環境を使用することになります」（佐藤氏）
また、リモートワークでCloud BuildとTerraform Cloudを使用するメリットとして、最初の定義やトリガーの設定などを一度実行してしまえば、構築する環境のパラメータを設定するだけで、同一構成のインフラ環境および、開発対象のコンテナイメージのビルドやデプロイが可能であることを挙げた。
さらに、インフラの構築およびソフトウェアのビルド・デプロイの完全自動化が可能となり、ほぼワンクリックで実行できること。開発したソースファイルや設定ファイルなどは、共用リポジトリなどで管理が可能となり、ビルドやデプロイの履歴管理およびブランチ作成による個人用の個別開発環境の作成も容易に実施できることが説明された。
最後に佐藤氏は、新型コロナ感染症の感染拡大が収束しても、ニューノーマルと言われるリモートワークは継続する可能性が高いことから、地方に住む優秀なエンジニアの採用や、環境の共有が容易なクラウドを活用していきたいと語り、セッションを締めた。
Google Cloud INSIDE Games & Apps 登壇情報
4月13日に開催されるオンラインイベント「Google Cloud INSIDE Games & Apps」に、grasysのエンジニアが登壇します。
