この記事は クラウドワークス Advent Calendar 2018 の1日目の記事です。
はじめに
クラウドワークスでSREとして働いている @kangaechu です。クラウドワークスには2018年9月に入社しました。
この3ヶ月にSREとして働いた中でこういう技術的な知識が必要だった、ここら辺をもっと勉強しておけばよかったということをまとめてみました。前職との間で感じたギャップも合わせて書いています。
ちなみに前職はエンプラ系SEで、職歴の前半はインフラエンジニアとして働いていました。メインフレームでJCL書いてたりExcelで設定一覧の表を作って手でサーバに反映してたりしてましたが何か？
SREとして働くのに必要だった技術的な知識
TerraformによるAWSのInfrastructure as Code
クラウドワークスではサーバのほとんどがAWS上にあり、構成はTerraformというツールにより管理されています。TerraformはAWSなどの構成をコードで管理することができます。たとえばEC2のサーバを1台立ち上げるのであれば、
provider "aws" {
access_key = "ACCESS_KEY_HERE"
secret_key = "SECRET_KEY_HERE"
region = "us-east-1"
}
resource "aws_instance" "example" {
ami = "ami-2757f631"
instance_type = "t2.micro"
}
のようなファイルを準備し、terraform apply コマンドを実行することで作成することができます。
前職ではオンプレのサーバを使うことが多かったのですが、AWSなどを使う場合はAWSのWebのコンソールからぽちぽちすることで作っていました。
インフラをコード化することにより、GitHubのPull Requestを使ったレビューが可能となります。
これにより、Excelのパラメーターシートを作ってレビューしてもらい、パラメーターシートから再度設定を作るような不毛な作業が不要となります。
また、変更の経緯や修正の履歴が残ることによりなぜインフラの構成を変更したのかを後で追うことができるようになります。
最初はどんなリソースを記述すればいいのかわからず悩むことが多かったですが、最近は割とサクサクとかけるようになり楽しいです。既存のリソースをTerraform化する作業をしているのですが、AWS自体のリソースについても学べたりと両側からキャッチアップできている感があります。
Terraformを学ぶためには Getting Started を事前にやっていましたが、結局は業務で使っているTerraformを触るのが一番勉強になった気がする。
クラウドワークスのTerraform職人である @minamijoyo のまとめが参考になります。
Docker
クラウドワークスサービスのいくつかはDocker化されており、残りのサービスも順次Docker化を進めています。
Dockerはアプリとその実行環境をコンテナという形でパッケージングし、実行・配布などを容易にすることができます。
前職で構築したシステムはサーバ本体にJavaなどの実行環境を直接インストールしていたので、バージョンアップ時の手順は課題でした。オンプレのサーバだったので戻し作業も簡単ではなく、システム切り替えまで先延ばしすることも多くありました。
Docker化により、どのコンピュータでも同じ環境を再現することができます。最近はAWS Elastic Container Service(ECS)やAWS Kubernetes Service(EKS)のようなサービスを使うことにより、クラウド上に作成したコンテナを簡単にデプロイ・実行することができるようになりました。
Docker化を進めるにあたり、Dockerがない時期に作られたサービスがほとんどのため、サービス内に状態を持つものは順次状態を持たないように修正する手間はありますが、動的なスケールアップ／ダウンやカナリアリリースなども今まで以上に簡単にできるようになるのでぜひ進めていきたいところです。
Dockerまわりはちょっと勉強していたことが役にたっているかなと思います。
Dockerはそんなに難しくないので、チュートリアルを終わらせて、身の回りのOSSを勝手にDocker化してプルリクを投げることで武者修行的に強くなれると思います。
さまざまなWebサービスの利用
クラウドワークスではサービスの開発・運用に様々なWebサービスを使用しています。主なところだけでも監視系だとDatadog、Rollbar、New Relic。GitサービスはGitHub。CI/CDにCircleCI。コミュニケーションにQiita:Team、Slack。などなど。入社時にもらうWebサービスのアカウントの多さにびっくりしました（ログインはGoogle認証なので楽なのですが）。
前職ではお客様のシステム構築時にはオンプレの監視ツール（Tivoliなんちゃらとか）を設定していましたが、運用チームは別チームのためどう使われているのかとかはよくわかりませんでした。また、監視系のサービスは落ちるとまずいので、構成が複雑になりがちです。
既存のWebサービスを有効活用することにより、本来の目的ではない監視作業をそれらに任せることができ、サービスの開発や改善に注力できるのはいいことだと思います。
また、監視系のサービスは自分たちが状態を監視する人でもあるため、監視項目やグラフを簡単に修正できるところもポイント高いです。
問題があったときもSlackを見れば今どうなっているかわかるというのもシンプルでいいですね。
全部のサービスについて詳しくなっているわけではないですが、使いながら学んでいるところです。最近好きなサービスはDatadogで、家でも使っています。
Webサービスを作る言語への理解
クラウドワークスのメインのサービスはRuby on Railsで作られています。コードはGitHubにあり、エンジニアであればアクセス可能です。
クラウドワークスに入って驚いたのはSREのメンバーもコードを修正してプルリクを出してもいいということです。前職であれば、「このコードのこの部分は〇〇さんの担当だから修正を依頼して」という感じでした。また、インフラのチームはソースにアクセスすることすらできないのが当たり前でした。
運用などで見つけた不具合も特定のチームに依存せず修正をしあうことができ、改善のしやすさや開発の効率化に一役買っているのではと思います。
私は7年くらい前にRails Tutorialを一度やったことがあるくらいで、まだまだコードをうまく読めないので、少しずつ勉強していきたいです。
まとめ
今回は自分がSREとして働き始める中で必要となった技術について紹介しました。
- TerraformによるAWSのInfrastructure as Code
- Docker
- さまざまなWebサービスの利用（Datadog、Rollbar、New Relic、GitHub、CircleCI、Qiita:Team、Slackなど）
- Webサービスを作る言語への理解（Ruby on Rails）
上記で挙げた項目はWeb系のSREであれば割とどの会社でも必要となるスキルセットではないかと思います。これからSREになろうという人はここらから取り組んでみてはいかがでしょうか。
エンプラ系のSIerからの転職時には見知らぬスキルが多くハードルが高く感じますが、自分もこれを書きながら「スキル足りないのによくSREになれたなー」と思うので飛び込んでみれば意外に大丈夫なんだと思います。