Googleが認めるManaged Service Provider事業

弊社は、Google Colud Platformパートナーとして認定されているMSPで、様々な会社のインフラ構築・運用をサポートしています。

ただ、私は元々インフラのエンジニアではありません。交換器のファームウェアの開発を行う会社で5年、先物取引のオンライントレードシステムを開発している会社で5年という経歴を持つ、バリバリのプログラマです。

その後は、gloopsという会社でソーシャルゲーム開発のメインエンジニアを担当しましたが、そのときの同僚が弊社代表の長谷川です。現在grasysは社員数5人という組織で、お客様の新規インフラ構築や、Google Cloud Platform以外のクラウドサービスからの移行をお手伝いしています。

クラウド上のインフラであれば、プログラマも活躍できる

私はデータセンターにラッキングして、設定して…という昔ながらのインフラの話には決して詳しくありません。ただ、IaaS（Infrastructure as a Service）というインフラがクラウド化されている環境では、プログラマの知識が活きる場所が数多くあります。

例えば、クラウドサービスを効果的に運用するためには、ミドルウェアをインストールするための補助スクリプトや、リソースを監視してビジュアライズするためのスクリプトが必要になります。

もちろん、リソース監視機能に限って言及すれば、nagios、munin、zabbix、cactiなど、歴史のあるリソース監視システムを利用する事も選択のひとつだと思います。私がgrasysに入社したときにはPerlで書かれたものがありました。

Perlにはcpanというライブラリが存在していて、様々な機能が簡単に利用でき、素晴らしいのですが、当時これらを利用した便利機能がCPUリソースを消費しすぎていることに気づいてしまったんですね（笑）。

そこで元々Go言語に興味があった我々は、これをGo言語で書き直すことにしました。結果、25%程度あったCPU使用率をほぼゼロにすることに成功し、それはもう、楽しい瞬間になりました。

ソフトウェアエンジニアだと、1つのプロダクトに注力していると使う技術の幅は広がり辛いという事があると思います。1つの技術を突き詰めるのも面白いのですが、弊社のようなMSPでお客様に合わせて様々な技術を学べることもまた一興です。

このままでいいのか、と感じていたり、新しいことを学びたいとプログラマには是非足を踏み入れてみてほしい領域だと思っています。活躍できるシーンも多いと思いますよ。

お客様がサービスを作り、我々が環境を構築するというケースが殆どですので、サービスの実装レベルでアドバイスができることもあります。そういう場合は、感謝されることがほとんどですし、ですから、認められないでくすぶっている人も活躍できるフィールドです。

余談ですが、最近入社してきた新人もプログラミング経験があるのですが、すでに大活躍中だったりもします。

Terraformで安全に、効率的にインフラを構築

弊社では、インフラを安全に効率的に構築するために、TerraformというOSSを活用しています。chefやansibleがサーバー内のミドルウェアを管理するのに対し、Terraformはインスタンスの構成を管理します。この環境にはWebサーバーのインスタンスが5台あって、ネットワーク構成がこういう形で、ということをコードで記述できます。

インフラ構成の冪等性を担保することは難しいです。Terraformはそこが上手くできていて、例えば「Webサーバーのインスタンスを5台立ち上げる」という設定で実行し、これが何らかの理由で失敗して1台だけ立ち上がらなかったとします。

その場合、次の実行時にはTerraformが良きにはからってくれて、足りない1台分だけを構築してくれます。実際は1から作り直したい場合もあるので、そのときは必ず5台全部作り直す設定にしたり、IPはそのままでインスタンスだけ作り変えるという事も可能です。

grasys流のTerraformの構成

Terraformには主にplanとapplyというコマンドを使います。planコマンドはいわゆるdry-runで、実行したら何が起こるかをリスト表示してくれます。その結果、問題がなければapplyコマンドで実際にインフラを構築します。

弊社では多くのお客様に対応するため、共通に使える設定をcommonテンプレートとして使いまわしています。その共通設定を上書きするファイルをお客様及びサーバ種別ごとに用意し、そこでイメージ名やインスタンスのタグ名、リソースの数といった項目を変更しています。

Terraformはインスタンスを作成後に任意のコマンドを実行できるため、そこでansibleなどによるプロビジョニングを実行できます。ただ、その構成だと起動までに時間がかかる場合があるので弊社では行っていません。その代わりに、一度構築したサーバーをインスタンスイメージとして固めてしまって、それを元にTerraformがインスタンスを作るようにしています。

手順書よりも確実な自動化へ

Terraformを使う最大のメリットは、やはり実行した形跡が残せることですね。インフラの構成が定義ファイルとして存在しているので、問題が起こった場合は何を間違えたのかすぐに分かります。

人間なので、ミスは必ず発生してしまいますよね。ただ、ドキュメントを元に1台1台コピペで設定するフローだと、コピペですらミスは発生するし、どこでミスしたのかも分からなくなってしまいます。だから手順書を書くよりも、コードとして残しておく方が確実です。

また、クラウドサービスの場合、インスタンスの起動時間に対して課金されます。手順書を見ながらゆっくり構築をしているとその分コストは掛かってしまいます。微々たる金額かもしれないですが、インフラの構築の自動化は確実にお客さまのメリットになります。

何もかも自動化したり、効率を追求する必要は無いと思います。何か障害が発生した時に「これを効率的に直すためにどうしよう」と考えてもしょうがないですよね。そんなことより早く直せよというパターンが多いです（笑）。ただ、インフラの構築も2回、3回と続くようであればTerraformのようなツールを使って仕組み化を考えたほうが良いと考えています。