はじめに
AWAでサーバサイドエンジニアをやっている山下といいます。初めてエンジニアブログを書かせていただきます。よろしくお願いします。
簡単に自己紹介をさせていただくと、2011年にSIerからサイバーエージェントに中途入社し、いくつかのコミュニティ系サービスの立ち上げ・運用、インフィード広告配信APIの作成などを経て、2015年4月からAWAチームに参加しました。
今回は、(今さら？な) DevOpsについてです。といってもスムーズな連携をするには といった話ではなく、現在のチームに参加してからというもの、「エンジニア間の役割が変わってきていて、DevOpsって現状にあってないんじゃないか」と感じており、それについてご紹介させていただきます。
AWAとは
定額制音楽配信サービスです。
スマートフォン、PCでアプリを提供しており、他のデバイスにも順次対応をすすめています。2015年のベストアプリにAndroid,iOS両方で選ばれました。
詳しい紹介はこちらをご覧ください。
同様のサービスとして、AppleMusic、GooglePlayMusic、KKBox、LINE Musicなどがあります。
DevOpsとは
私自身この概念に詳しい訳ではありませんが、調べると、
「開発(Dev)と運用(Ops)が協力し、システム開発をより柔軟、スピーディにし、ユーザー価値を最大化する」
ということのようです。
より具体的な私の解釈としては、
「アプリケーションエンジニア(Dev)とインフラエンジニア(Ops)が密に連携し、爆速開発してユーザー価値を高めよう」
です。
※便宜上エンジニアを以下のように区別します。
- アプリケーションエンジニア： サービス仕様を実装してアプリケーションを作る
- インフラエンジニア： サーバ作成やドメイン設定などを行う
私はアプリケーションエンジニアに属します。
これまでの開発の流れと問題点
AWAに来る前までは、ざっくり以下の様な流れで開発を行ってきました。
[アプリ]=アプリケーションエンジニアの作業
[インフラ]=インフラエンジニアの作業
とします。
リリースまで
- 担当してくれるインフラエンジニアが決定
- そのエンジニアと相談し、システム構成について決定
(DBはMySQLで何台、アプリはnodejsで何台など) - [インフラ]ドメイン、DNS、証明書の取得・設定
- [インフラ]インスタンス、LBの作成・設定
- [アプリ]仕様の実装
- [アプリ・インフラ]負荷試験
- リリース
リリース後：サーバを追加したい場合
- [アプリ]サーバのミドルウェア構成やスペック、台数、期限などを伝える
- [インフラ]構築
- [インフラ]完了連絡
- [アプリ]確認
- [アプリ]確認完了
このように、アプリケーションエンジニアとインフラエンジニアの担当領域が明確に分かれていました。私が担当していたのはアプリの部分だけで、インフラ側については依頼するだけでした。
サーバが欲しければ、「nginx,javaが入ったスペックこれくらいのサーバを来週までに2台ください><」と依頼していました。
このやり方では、安心感はあるものの、「依頼→(待ち)→できたよ→確認します→(待ち)→OKです」 といったやり取りが毎回発生し、お互い「連絡待ち」の状態のまま数日たったということもよくありました。特にインフラエンジニアは複数のサービスの担当をしているのが普通なので、今すぐにお願いします！というのも気が引けます。。
DevOpsが目指す「スピードと柔軟性」があまり実現できていない状態です。
AWAの開発体制
エンジニア以外にも多くの人が関わっていますが、ここではエンジニアだけの紹介にします。
- サーバ: 4人
- スマホアプリ: 各5人
- Web、PCアプリ: 5人
- インフラ: 0人
担当インフラエンジニアがいません。
(あくまで担当がいないだけで、色々相談を受けてくれる人はいます。いつもありがとうございます。)
AWAに来て変わったこと
これまでインフラエンジニアに依頼してやってもらっていた部分を、アプリケーションエンジニアが担当しています。
具体的には、
- DNS、ネットワークの設定
- インスタンス、LBの作成・設定
- CDNの設定
- リソース監視の設定
- SSL証明書の更新
などです。
まさか自分が証明書の更新を行うことになるとは思ってもみませんでした。
元々、ネットワーク設定周りなどインフラ関連に苦手意識を持っていたので、チームに参加した時そこも担当範囲だと聞き、衝撃を受けました。焦りまくって色々勉強しなおしました。。
自信のないところは、
「ああ、あれね (どれ？)。Aさんどう思う？(ごめんなさい)」
でかわしつつ、その間にこっそり聞いたり調べたりしてます。
今でも苦手意識を克服できたとは言いがたいですが、たいぶマシになったはず、、です。
使っているツール類
一部ですが、実際にAWAで使用しているツール類をご紹介します。
バックエンドはAWS(一部GCP)を使っています。
サーバ群の管理にはWebコンソールは使用せず、下記のツールを使っています。
これらのツールの設定ファイルは、Githubに専用リポジトリを作り、バージョン管理をしています。新しく参加したメンバーも、このリポジトリを見れば現在のシステム構成を把握できます。
ただし、terraformはCloudFrontに対応していないので、そこはWebから設定しています。
(2016/02/15現在 プルリクエストは出されている)
例として、新規サーバの作成は以下の手順で行います。
- ansibleとpackerでAMIを作成する
- terraformの設定ファイルに、インスタンスの種類やサイズ、LB、AutoScalingのしきい値、セキュリティグループ、DNSなどの指定を書き、プルリクエスト＆レビューをしてもらう
- レビューOK後、terraformを実行してインスタンス作成を行う
上記作業は全てアプリケーションエンジニアが行います。
初めて本番環境に terraform apply した時のドキドキ感といったら。。もし設定をミスっていたら、障害を起こしてしまうわけで、今でもあまりやりたい作業ではありません。。
精神的な健康を保つため、チーム内のローカルルールとして、
- 実行前に必ず
terraform planの結果をレビューしてもらう - 実行時に必ず
-targetオプションを付与して変更対象以外のサーバに影響がないようにする
などを決めています。
そのおかげか、これまで本番環境で特に大きな障害は発生していません。
DevOpsがどうなったか
これまでの手順からどのように変わったのか、サーバを追加したい場合を比較します。
- terraform設定を書く
- プルリクエスト&レビュー
- 実行
上述のこれまでの手順とくらべて、「待ち」が減り、実際の作業はアプリケーションエンジニアが行うようになりました。
アプリケーションエンジニア(Dev)がインフラエンジニア(Ops)領域も担当することにより、開発スピードは大きく向上しました。
「依頼→できたよ→確認します→OKです」 のやり取りがなくなり、インフラ関連で何か欲しければ、自分で設定を書いて実行すればよくなったからです。
その分、責任を負う範囲も増えましたが、インフラまで含めたシステム全体を把握しなければならないという意識が強まりました(それができているかは置いといて)。
また、問題が発生した時に、アプリケーションからネットワークまで全体を見て、問題を特定し、解決法を模索、実施できるようになり、「スピードと柔軟性」というDevOpsが目指すものに少し近づけた気がします。
インフラエンジニアとの関わり方の変化
これまでは、インフラエンジニアもサービスのエンジニアチームの一員として、がっつり議論の場に参加してもらったりしていましたが、AWAではそれが変化しており、
- 原因が突き止められないトラブルの相談
- インフラ構成変更のプルリクエストのレビュー
- DBの新バージョンの検証結果フィードバック
など、少し下がった位置からのアドバイザー的になっています。
障害発生時や負荷試験時になると颯爽とあらわれて、助言・解決したら去っていくようになりました。
「このDBのこのバージョンはこういうバグがあるから1個前のバージョンのほうがいいよ」
「terraformのこのバージョンはこの操作をするとここがおかしくなるよ」
といった、ググっても見つからないようなノウハウを共有してもらったりしています。
DevOpsの意味と今後
アプリケーションエンジニアがインフラ側に進出するようになったことで、インフラエンジニアはサーバ構築・運用の作業時間が減り、その分、
- terraformって運用に耐えれるのか？その管理方法は？
- 属人化しないリリースフローとは？
- つまり、インフラ構築をどうやってよりスムーズにかつ安全に実現するか？
といった、より本質的な課題の検討・検証にあてる時間が増えてきたと聞きました。
従来のDevOpsが指すDevとOpsはすでに区別がなくなっていて、それを踏まえた上でさらにどうするのかを考えなくてはいけないと感じています。
AWSやGCPなどの、いわゆるクラウドサービスが当たり前になる中で、今後この流れは強まっていくのではと思います。
さらに、AWS Lambda のようなサーバレスの仕組みが当たり前になると、そもそもサーバサイドエンジニアって何？ということになるかもしれません。
まとめ
AWAに参加して感じた、エンジニアの役割の変化についてご紹介しました。
現時点では差別化になっている技術や知識であっても、どんどんコモディティ化していく中で、エンジニアとして今後どうしていくべきなのか？という課題について、引き続き考えていきたいと思います。
最後まで読んでいただきありがとうございました。