こんにちは、Webアプリケーションエンジニアをやっています、すてにゃん ( 
id:stefafafan ) と言います。私は16卒のエンジニアで、今回初めて割と大きめなタスクを調査からリリースまで担当したので、その一連の流れを紹介していきたいと思います。
Mackerelとははてなが運営しているサーバ監視サービスです。
mackerel.io
Mackerelでは以前AWSインテグレーションという、AWSクラウド製品の管理・監視ができる機能が実装されました。
mackerel.io
今回私はAzureインテグレーションという機能を実装しました。この記事ではこちらの機能のリリースまでのプロセスを紹介します。
mackerel.io
準備
まずAzureインテグレーションを開発する前に、実際どういう仕様にするか、どのエンジニアがメインで担当するのか、工数はどれくらいかかりそうか、どのような形にMackerelとAzureが連携できると嬉しいのかなど色々と考えることがあります。現在Mackerelチームは開発手法としてはスクラムのような形を取っていて、2週間スプリントです。その中で毎週1度は開発メンバー全員集めて次のスプリントやることを決めたり見積もりをしたりします。今回のAzureインテグレーションに関してはスプリント会とは別にAzureインテグレーション見積もり会を開催して大まかに見積もりをしました。
見積もり会
この時点ではまだ開発を始めていないので具体的にどの工程で躓くのかなどはまだわかりませんが、今まで作ってきた機能なども考慮しつつ大体こういう工程が必要だろうというものを思いつく限り列挙しました。その後開発メンバー全員集めて見積もり会を開催しました。工数はプランニングポーカーを使って見積もりしました。開発メンバーは現在東京と京都と愛知で別れているのでGoogleハングアウトごしに数字を出しあっておおまかな工数を割り出しました。自分はこの規模の機能を担当するのは始めてだったので、この段階で「あ、これくらい大物タスクなんだ」というのが数字で実感できたのでよかったです。また、最低これくらいの期間はかかるだろうなというのがもっと上手くイメージすることができたのでよかったですね。
Azureインテグレーションの場合は大体以下のような工程が必要ということがわかりました。
- 調査
- クローラーの開発
- デプロイの相談など
- Mackerel本体のAzureインテグレーション対応
- Mackerel本体側のデザイン依頼
- 動作確認
- ヘルプドキュメント作成
デプロイ先の用意やデザインの調整はシステムプラットフォーム部のエンジニアとデザイナーさんに依頼しますが、それ以外の多くの事はアプリケーションエンジニアがやります。
調査
私はAzureをちゃんと利用したことがなかったので、まずはAzureのサービスについて調べたりAzure PortalやCLIツールを実際に触ってみたりしてAzureになれるところから始めました。ただ今回実装する機能はAzureのサービスのメトリックをMackerel側でまとめたり監視したりアラート通知したりできる機能なので、主に以下のことの調査が必要でした:
- アクセス権限周り
- SDK/API周り
- 料金周り
アクセス権限
MackerelとAzureの連携を利用するということは、Azureにあるメトリックの情報がMackerelに投稿されるということです。このメトリックの情報が何らかのミスにより例えば他のお客様に漏れてしまったり、もしくは誤ってMackerelが書き込み権限を持ってしまいお客様の環境になんらかの操作をしてしまうようなことが起きてしまうと大変なので、アクセス権限周りは念入りに調べて動作確認も慎重にしていきました。
Azureの場合はサービスプリンシパルという仕組みを利用して、Mackerelのアプリケーション専用のものをお客様に作ってもらい、しかもReaderロール（閲覧権限）以外持ってる場合は操作を一切しないようにすることに決めました。AzureのActive Directory周りなどについては個人ブログに軽く書きました。
stefafafan.hatenablog.com
SDK/API周り
サービスプリンシパルを作成し、閲覧権限でAzureのリソースを参照できるようにしたところで、次にメトリックの取得ができないといけません。メトリック以外にもMackerelのホスト詳細画面などでそのリソースに関するメタデータなどが表示されていると便利そうなのでそういった情報も取得できないか調べていきました。Azureに関しては公式がGitHubにてSDKを色んな言語で公開していたのでそれらのリポジトリをみて実際に利用してみたり、READMEとドキュメントの他にIssueやPull Requestに一通り目を通していきました。APIドキュメントもみつつ、APIリミットなどについても確認しました。
料金周り
現状APIだけの利用ですが、実際にどれほどの制限があるかなども調べました。むやみやたらに叩きまくるのはAzure側も困りますし、Mackerelを利用しているお客様に請求がいくのは嬉しくないので常識の範囲内で叩くようにしようということになりました。
azure.microsoft.com
再見積もり
この時点でAzureインテグレーション見積もり会で見積もった調査にかかる工数をすでにわりと超えてしまっていました。雰囲気をもっとわかったところで改めて見積もりし直しました。また、バーンダウンチャートもZenHubで作ったので、大まかにどういうペースで進めていけば開発が終わるのかイメージがつきやすいです。ここから先はわりとこの再見積もり通りにスケジュールが進んでいきました。
www.zenhub.com
クローラー
Azureインテグレーションの構成としては以前チームメンバーが実装したAWSインテグレーションに近い構成を取ろうということになったので、AWSインテグレーションと同じようにAzureのリソースの取得とMackerelへの投稿を行なってくれるクローラーを作ることになりました。既存のシステムに近いものを作るのは楽で良いですが、開発が終わった後似たようなクローラーを複数メンテナンスするのも少し面倒そうというのもあるので少し考えたほうが良いかもしれません。（今回はとりあえずAWSインテグレーション用とAzureインテグレーション用でわけて作っています）。ちなみにMackerelチームではこういうものはよくgolangで書いています。
方針相談
突然作り始めるのではなく、クローラーの構成や仕様についてある程度自分で考えて、GitHubのissueに書き連ねていきました。Mackerelチームは現在GitHubとChromeのZenHub拡張機能を利用し、カンバン的なタスク管理を行なっています。Pull Requestだけではなく、こういった方針相談などもissueで行なって「レビュー依頼」レーンに移動させてチームメンバーにレビューしてもらうようにしています。チームメンバーがAWSインテグレーションを開発した際の方針相談issueも検索したらあったのでそのissueやそのときのKPTなども参考にしつつ書いていきました。issueに関連するissueやPull Requestを一緒に書くようにしておくと、こういう風に過去にやったことを参照する時とても便利だなと思いました（コードならgit blameしていくのも良さそうだけど）。
クローラー自体の構成のほか、APIを叩く頻度や最初に対応するAzure SQL Databaseで取得するメタデータ、Mackerelのグラフにするときにどのメトリックを一緒にまとめるか、権限のチェックを具体的にどういう風にやるかなど書いていって相談しました。
「Mackerelのグラフにするときにどのメトリックを一緒にまとめるか」というのは最終的に出来上がったドキュメントをみるとわかりやすいと思います。connection_successfulやconnection_failedのメトリックを一緒のグラフにするかどうかみたいな話ですね。
mackerel.io
実装
方針が決まってきたところで、実装に入ります。方針で決めた通りに進めた上に、AWSのクローラーも参考にしていったのでわりとスムーズに進んだと思います。（この時点で出来たやんという気持ちで居たけど後々いくつかミスってることに気付きました）
デプロイの相談
お客様の権限でメトリックを取得しMackerelにメトリックを投稿してくれるものが出来たところで、これのデプロイ先を決めないといけません。はてなではWebアプリケーションエンジニアとWebオペレーションエンジニアと職種が別れていますが、インフラ周りはWebオペレーションエンジニアの方が担当していますのでその担当の方に相談します。こちらもGitHubのissueやSlackでのやりとりがメインとなります。
Slackといえば、元々#infraチャンネルというのがありそこで相談などしていましたが、最近は#infra_mackerelというWebオペレーションエンジニアの方々とMackerelチームのエンジニアが所属しているチャンネルができたので、相談事がもうちょっとまとまって対応しやすくなったかと思います。
Mackerel本体
Mackerel本体側でやることというと、Azureインテグレーションの設定画面の作成や、Azureインテグレーションの設定の保存もする必要があるのでテーブル設計、クローラーとの連携などです。こちらも方針を先に相談するつもりでいましたが、クローラーの方針相談の際に大体できていたので、わりとすぐ出来ました。
デザイン
主にAzureインテグレーションの設定画面ですが、デザイナーさんにデザインをみてもらいます。Mackerelチームのデザイナーさんもエンジニアと同じようにGitHubのZenHub連携を利用しタスクを管理しています。依頼フローとしてはエンジニアがタスクを実装できたと思ったらそのissue/Pull Request上でデザイナーさんにデザインを依頼し、デザイン調整が終わったら「レビュー依頼」レーンに移動し次にエンジニアにコードレビューをしてもらう、という感じです。デザイナーさんもgitが使えてテンプレートファイルやLessファイルに手を入れて直接ブランチにpushしてくれるのでとても助かっています。
動作確認
クローラーも本体側の対応も終わり、もうリリースできるのでは！と一瞬思いましたが、とても大事な機能であるし、落ち着いて動作確認を念入りにしたところ案の定バグがいくつか見つかりとても焦りました。これはいけないと思い、自分で動作確認用にチェックリストを作っておき、staging環境で確認、本番環境ではてな社員限定オーガニゼーションで再び確認、お客様向けリリースで更に確認していきました。
AzureではActive Directory内に複数のサービスプリンシパルを作成したとしても、Tenant IDは固定なので、複数のTenant IDで動作確認したいときはDirectoryごと新しく作る必要がありました。いろんな環境や状態のことを考慮して動作確認していくことは少々面倒に思うかもしれませんが、本番リリース後に不具合に気付き慌てて修正してリリースし直すのは絶対に避けたいところなので、細かいところまで修正していきました。ここまでやったおかげで、お客様向けにリリースしてからは大きな不具合は今の所見つかっていないです。自分で動作確認を徹底しておいてホッとしています。
ドキュメント
Mackerelのヘルプドキュメントも結構大事だと思っていて、ここも私が詳細に書きました。
mackerel.io
Azure CLI 2.0での連携方法とAzure Portalでの連携方法について書いた上、シークレットキーの有効期限など気になりそうな点についても出来るだけ詳しく書くようにしました。
このドキュメントも自分が書いてそのまま公開したというわけではないです。このヘルプドキュメントもGitHub上で実は管理されていて、Pull Requestを出してチームのメンバーにレビューしてもらって（Azureインテグレーションのヘルプの場合はエンジニアのほかにデザイナーの方などにもみてもらいました）、その上良さそうであれば公開しました。Azureをあまり使った事ないメンバーに実際にヘルプドキュメントを観ながら連携の設定をしてもらって、わかりづらい点などフィードバックしてもらって非常に助かりました。
その後
Azureインテグレーション機能をリリースし、ドキュメントも公開した。これで終わりかというと全然そんなことはなくて、メンテナンスなどしていく必要もあるし、なんらかの不具合が見つかる可能性もあります。また、Azureインテグレーションは現在Azure SQL DatabaseとAzure Redis Cacheに対応していますが、他のクラウドサービスにも対応していく必要があります。メンテナンスや機能追加は私がこれからもメインでやっていくのでしょうか？そうとは限らないと思いますし、出来ることならチームのいろんなエンジニアがある程度触れるような状態だと嬉しいと思います。ということで、開発中もGitHubのissueなどにAzureインテグレーションの開発のときに気づいた点など書いてましたが、改めてまとめることにしました。
社内ドキュメント
自分以外のエンジニアがAzureインテグレーションに機能追加する際、どこから始めれば良いかわかるように、クローラーのREADMEを充実させました。具体的に何をするものなのか、依存するライブラリの説明、ローカルでの実行の仕方、Azureの認証周りの説明、Azure自体の仕様の説明、など一通り書いたので、いきなり他のエンジニアが触ることになってもものすごく迷うみたいなことにはならないはずです。
技術勉強会
はてなでは毎週木曜日エンジニアやデザイナーが二人発表する技術勉強会というものがあります。ちょうど私の出番が回ってきたのでAzureインテグレーションの際に溜まった知見をそこでも発表しました。READMEやチームの日記にAzureの件を書くと、チーム内の知見は深まりますが、チーム超えてだと中々そうはいかないので、こういう技術勉強会の場で発表すると他のチームの人にも知見がいくので良いです。また、エンジニア全員が所属する社内日記もあるので、そこで知見を書いていくと他のチームのエンジニアにも読んでもらえるので良いですね。
公開ブログ
例えばこのブログですね。チームへの共有、社員への共有の他に、社外向けにアウトプットするのも大事だと思います。そう思って私もいまこの記事を書いています。
KPT会
チームでAzureインテグレーションのKPT会も開催しました。メンバーがいろんなところにいるのでハングアウトつないでGoogleスプレッドシートでやりました。ここで自分が気になった点やよかった点をいろいろ挙げる事ができたのでよかったです、次回以降の開発にも活かせると良いですね。
感想
はじめに書いた通り、私は今回初めてこのような大きめなタスクを最初から最後まで手がけました。調査の段階から自分でやったのもあったせいか、結構責任重大という気持ちが強くて、特にアクセス権限周りの動作確認を本当に念入りにしないとという気持ちでいっぱいでした。またどんなに念入りに動作確認したとしても、100%完璧なコードを書いたとは絶対には言えないと思うので、経緯や感じたことなどなるべくドキュメントに残しておこうと思いました。
結構緊張感はありましたが、いろんなレイヤーのことを意識したり調査したりコード書いたりとできたので、とても良い経験だったなぁと今思ってます。それなりに完成するまで時間はかかりましたが、自分がやってきたことがちゃんとリリースまで行くと嬉しいものですね。これからもがんばっていきたいです。
