はじめに
こんにちは！FJCTエンジニアタスクフォース（ETF）の衞藤です。「FJCTQualityUp」連載4本目の本稿は、「FJcloud-V/ニフクラの各サービスと連携する通知システム」のテーマでインタビューした記事になります。
前回の「FJCTQualityUp」の記事は
【FJCTQualityUp #3 】マイクロサービス開発への取り組み - FJCT Tech blog
です。気になる方はそちらもご覧ください！
FJCTQualityUpについて
こちらの連載記事では「FJCTQualityUp」と題して、富士通クラウドテクノロジーズ株式会社（以降FJCT）のエンジニアに「FJCTのサービス品質向上のために何をしているのか」をインタビューしていきます。
エンジニアの生の声が、これからエンジニアを目指す方、今まさに課題解決に取り組んでいる同業者、その他大勢の方にとって参考になる、そして明日からの実践のきっかけになることを願っています。
第4回：FJcloud-V/ニフクラの各サービスと連携する通知システム
自己紹介
衞藤：今回は、「FJcloud-V/ニフクラ（以降ニフクラ）の各サービスと連携する通知システム」をテーマに、ニフクラの通知システムの開発・運用を担当するCRE部所属の2人にインタビューしていきます。まずは、自己紹介をお願いします！
海野：海野晶平です。2016年入社の8年目になります。入社当初はニフクラサービスの開発・運用を行うプラットフォーム部に配属されましたが、数年後にニフクラを利用するお客様に様々な情報を通知する仕組みを刷新させるためにCRE部に異動して、通知システム全般の設計・開発・運用を行っています。
小林：続いて自分ですね。小林遼爾です。2020年入社の4年目です。入社当初からCRE部に配属され、担当は海野さんと同じく設計・開発・運用です。僕がちょうどこのチームに入るタイミングで、新しい通知システムがリリースまであと1か月という状況でした。海野さんとはトレーナー・トレーニーの関係です。あと、インタビュアーの中井くんとは2020年入社の同期です。
海野：あっ、そうなんだ。
衞藤：そうなんですね。
中井：そうですね、よろしくお願いします。こうやってカメラオンで会うのも久々ですね。。
衞藤：確かに4年目くらいだと会う機会って少なくなるよね。
中井：配属後はめっきり少なくなりました。
衞藤：今日は同期だからこその話も聞けることがあるかもしれませんね。
顧客通知システムについて
衞藤：そもそも通知システムと呼ばれるものは、どのようなものになるのでしょうか？
海野：ニフクラの障害・メンテナンス・お知らせの事象に応じて、社内の各サービス担当が情報を入力すると、事象を発信するべき対象のお客様に必要な情報をメールで通知する、そしてニフクラのコントロールパネル（以降コンパネ）・APIでもお客様側への通知内容やサービスの稼働状況を確認することを実現するシステムとなります。
現在の通知システムができるまでは、どのリソースが障害の対象になっているか、いつメンテナンスがあるかをメールの通知だけで行っていました。ただ･･･メールの通知だけだと通知情報を追いにくく確認しづらいというお客様からの声や、競合他社がWeb上で障害やメンテナンスの情報を確認できるサービスを行っていることを踏まえて、現在の通知システムの開発を行いました。
衞藤：コンパネやAPI上で、お客様に対して通知内容を表示する機能を実現しているということですね。例えば、通知を出すにあたって、メンテナンスや障害がどこで起きているのかの情報をサービスから取得する必要がある印象を受けました。実際、色々な情報の基盤に繋がっているシステムなのでしょうか？
海野：そうですね。色々な情報に繋がっていると言いますか、ニフクラの様々なサービスの内部システムに対してリクエストをかけ、自分たちのデータベース上に各サービスのリソース情報を集約して、その集めた情報を元に通知を出しているというものになります。
衞藤：では、かなり大規模なデータベースになりますかね。
海野：そうですね、ニフクラのリソースの情報をほぼ全て集約していますので、かなり大規模になります。
FJCTで顧客通知システム開発に取り組みだした背景
衞藤：そもそも通知システムを開発したきっかけはどのようなものになりますか？
海野：以前使われていた障害の通知システムには様々な問題があり、お客様から分かりづらいという声を多くいただいていたこと、内部的にもより分かりやすい通知を出したいという強い思いがあったことが開発のきっかけでした。様々な問題の中身としては、一つが「送信処理時間」です。メールで送信する処理だけで障害の規模によっては長くて1時間以上かかってしまうケースがありました。二つ目は「通知の対応工数と大量のメール」です。最初に発生した障害から波及して別のサービスに障害が起こるケースがあるのですが、その場合各サービスごとに障害の影響情報を手動で収集し、サービスごとにメールを送ります。そのため調査に時間もかかり送信にも時間がかかり大量のメールが1つの障害で送られてしまいます。最後に三つ目の問題は「UIの煩雑さ」です。障害の通知を送るために入力するUIの項目がサービス担当から見ても分かりにくいものになっていて、通知運用が負担になっていました。これらの問題を改善しつつ、開発の過程でメンテナンス通知・お知らせ通知も含めた形で刷新を行い、利便性向上を目的に通知をメール以外で確認できるようにサービスアクティビティを新たに開発しました。
衞藤：内部の課題感やお客様の改善要望の声があり、プロジェクトとして立ち上がった形になるのですね。お話を伺っているとサービス間で連携する部分が多い分、プロジェクトを進めて実際にシステムにして行く過程で、多くの課題があったのではないかという気がしています。どういった課題があったのか、それに対してどういう解決のステップを踏んで行ったのか等、聞かせていただけますか？
海野：まず障害を通知するメールの送信自体に多くの時間がかかってしまう「送信処理時間」問題に対しては、既存システムを改修することが難しかったため、新たな言語で0から開発を行い、刷新の中で可能な限り処理の並列化などを行い速度改善をしました。
海野：次に1つの障害から複数のサービスに障害が波及したときに、各サービスごとに影響対象を調査し、文面を作成し通知を送っていたためお客様に大量にメールが送信されてしまう「通知の対応工数と大量のメール」問題。これはメールを受け取ったお客様はメールが多すぎて障害がどういう状況になってるか分からないという課題と、社内の各チームの人たちも障害の対応しながら影響対象をリストアップして通知するという内部的な作業量の課題がありました。
海野：そういった課題に対しては入力された1つ目の起点となる障害から関連する障害を自動で取得できるように、ある障害から関連して起こる障害をJSONで定義するスキーマを作成し、その定義に則って仮にAという障害が起きたら関連してBという障害が起こるのでAとB両方の影響対象情報を取得し、文章を作成し複数の障害を1通のメールで送るという処理にして、各チームの対応工数とメールが送られるまでに必要な調査の時間を減らし、メールの数自体も減らすことことで課題を解決しました。
衞藤：お客様や社内のチームのことを考慮して、綿密に設計されてシステム化を推進されていたのですね？
海野：そうですね。過去行われた障害の通知を分析してシステムの設計に落とし込みました。あとは、それまでのシステムでは通知を送る際の入力項目が煩雑となっていた「UIの煩雑さ」問題は、簡単に入力できるように障害の通知の分析結果を用いて最低限の項目に整えています。
衞藤：実際に障害が起きたときは対応がすごく大変ですよね。他にも色々な対応しなきゃいけないことがあり、その中で通知にはできるだけ手間をかけずに、できるだけ早くお客様にも伝えなきゃいけない。そのフローの整理もできたというところは、非常に良い改善だと思いました。
海野：そうですね。お客様への通知までの時間が圧倒的に減ったことと、メールの数が減ったことは大きかったです。また、これまでは通知を送ってもメールでしか確認できなかった点が、コンパネやAPIでお客様がいつでも確認できるようになった点が大きいですね。
海野：やはりメールだけだと確認が難しいかなと。メンテナンスをいついつ実施しますと言われても、実際はメンテナンス実施2週間前などに通知するので忘れてしまうこともありますし、自分でメンテナンス日程をカレンダーにマッピングしなくてはならなかったりと把握が難しかったと考えています。現在の通知システムですとカレンダー表示でメンテナンスがありますという告知を表示でき、お客様が以前より分かりやすいようになっています。
衞藤：かなりお客様の目線で考えなきゃいけない部分にも携わっているということですね。
海野：そうですね。障害の通知に関しては社内のサービス担当者が使いやすいことを考えなくてはならない一方で、通知内容や通知が送られた先の話に関しては、お客様が見やすいとか分かりやすいみたいなことを考えなくてはならないですね。
新たに出てきた課題
衞藤：今の通知システムを提供するうえで過去課題になっていたこと、現在も課題になっていること、それに対してどういう風な観点で解決に取り組んでいるのか？みたいな話も聞きたいですね。
小林：過去大規模な障害が起きた際に、私たちの通知システムでメールが送れなくなる状態が発生したことがありました。そういった場合にも私たちはお客様にいち早く情報を届けることが使命となるため、その時のようなことは発生させるわけにはいきません。極端に言えば、ニフクラが完全に止まった場合も考慮した可用性の向上が課題と挙げられますね。現在も基本的にはKubernetesやプライベートブリッジを用いて複数リージョンで冗長構成を組んで可用性は高くしているのですが、まだ一部検討できそうな部分もあります。あとは将来的に他社のクラウドなども活用してマルチクラウドで対応することも検討しています。もし万が一ニフクラが完全に停止しても通知は出せるシステムを将来的に考えてたりしますね。
衞藤：確かに障害の通知を出すシステムが障害で落ちると障害が起きているか分からなくなるので、すごい分かりやすい例だなと思いましたね。
海野：通知システムのリリース当時は単一のリージョンでしか稼働しておらず、可用性を上げるために様々な対応をしましたね。
小林：データベース自体もMySQL InnoDB クラスタを用いて複数リージョンで冗長構成を組んでいるので、可用性という意味ではだいぶ保たれている状況です。
衞藤：そういった意味だと、社内でも率先してマルチクラウドを利用していける。率先して取り組んでいかなきゃいけないシステムなのかなという印象を持ちました。他には気にしている点とかありますか？
小林：障害やメンテナンスはお客様に通知する文面をテンプレート化して用意しているのですが、運用する中でテンプレートの内容が分かりにくいという問題が見つかるたびに改善していますね。
衞藤：お客様に情報が伝わりやすくするための改善もしてるということですかね。障害が起きたことをいち早く通知できる部分は何か工夫されているのでしょうか？
海野：そうですね。一部の通知に関してはAPI連携をしていて、サービスの監視システムが障害を検知して私たちの通知システムのAPIにリクエストを投げることで、自動的に障害の通知がお客様に送信されます。小林君が対応してくれてるところですね。
小林：ありましたね。
海野：そのようにして送る時間をできるだけ速くする努力をその他のチームと連携して取り組んでいます。
衞藤：たしかに弊社では自動で障害の通知が出るサービスも多い印象です。そういうサービス開発者の設計上の工夫で、より早く情報を通知する仕組みが実現できるということですね。
今後の取り組み
衞藤：今後お客様に対して障害の情報を早く通知したり、色々な情報を適切に提供していくことはサービス品質を考えるうえで非常に重要ですね。可用性の点以外に、今後取り組んでいきたい、例えば実装したい機能等で何かこういうことができたらいいよねと思われていることはありますか？
海野：そうですね。例えば、データベースと各サービスが連携をするときに、統一しているフォーマット指定が現在ありません。APIでこういう情報を返しますとか、データベースでこういう情報が取れますという仕様を新しいサービスをリリースするたびに各チームと連携して実装する形になっています。この辺りにある程度ルールを決めたいと考えていますね。
海野：具体的な検討はできていませんが、各サービスからデータを取得するコードをAPIの定義などから自動生成するようなことをやって行きたいなと考えてたりはします。意外と各サービスとの連携は運用工数がかかったりしてる状況があるので、そのあたり工数削減したいなと。これが実現すれば通知システム側もサービス開発側もコスト削減できて良いですね。
小林：それ以外にも、障害の通知を出すための社内向けのUIがあるのですが、入力した情報がどのようにコンパネに表示されるのかがサービス担当に分かりにくいという課題もあります。
海野：背景としては、障害の通知システムを最初にリリースした後に、メンテナンスとお知らせの通知システムとコントロールパネルとAPIで確認ができるサービスアクティビティを追加開発し、リリースしました。その兼ね合いで障害の通知システムとサービスアクティビティの連携が複雑になってしまい、その結果入力者が分かりづらい状態になっている現状があります。そのため、障害の通知システムもメンナナンスとお知らせの通知システムに統合して1つのシステムとして管理していきたい思いがありますね。
衞藤：色々なサービスと連携をするという側面は、マイクロサービスの開発の仕方と関連する部分が多そうですね。
衞藤：世の中でいまDXというワードはもうだんだん下火になってきたかなという感覚もありますが、DXで挙げられる内容がこの通知システムとかDBの集約みたいなところで実現されている部分がありそうですね。そのうえで今後も色々なところと統合していかなきゃいけないという課題感も聞かせていただけないでしょうか。
海野：データベースに関しては、取り扱うための情報が多いので今後システムの追加や改修によって破綻することなく利用できるテーブル設計をしなければいけない難しさはあります。中には敢えてDB設計のアンチパターンを踏んで作っているようなところもあったりします。処理によっては、UNIONやJOINを使い10個ぐらいのテーブルを参照するようなSQL文があり、多くのテーブルを扱ううえで大変な部分もあります。
衞藤：テーブル自体の設計の部分と、それをどう結合して扱って処理を進めるかみたいな部分ですよね。
海野：どこにどういうデータを入れるかとか、新しいサービスができたときにこのテーブルを使い回すとかは毎回検討する必要が出たり、その辺は大変ですね。小林君何か補足ありますかね。
小林：新しいサービスが出たときは、障害リソースの抽出の仕方をどうするかを結構話しますよね。その度に抽出のロジックを新しく追加する必要があったりとか。今後もどんどん増えていくと思うので、結構大変そうだなと。
海野：連携に関するルールとかを決めて、自分たちの抽出ロジックに関しても同じようなことを適用して、より他チームとの連携をしやすくしていきたいですね。
ここまで読んでくれた方へ！
中井：本日はインタビューありがとうございました。最後にチームとして今後どういった方に来ていただきたいとか、こういう人は向いてるかもとかありましたら是非メッセージをいただければ。
海野：今はそんなに技術知識がなくても積極的に勉強して手を動かせるような人であれば向いていると思います。実際僕もそうですし、小林君をはじめその後に入ってきた後輩もそうですが、入社時点でゴリゴリにコードを書けたりすごい技術力がある人はいなくて、入社してから勉強する中で技術力をつけてきた人が多いです。
小林：弊社のサービスを俯瞰的に見られる社内では珍しいシステムですので、その辺に面白さを感じられる方はマッチしていると思います。社内に対して、我々ならではの視点からの提案ができることもあります。我々しか気づけない事象とか、例えばメンテナンスが多い箇所はどこかとか。
海野：障害やメンテナンスがどれくらいあるのかを確認できるのは、やっぱり自分たちのチームだけですね。その情報を見て、サービス提供しているチームに提言できることがあるのではないかというのが最近チーム内で話題になりましたね。
小林：そういうことにワクワクする人とかは向いているのかなと思いますね。
衞藤：お客様にも社内の運用者にも良い環境を提供したい、お客様側向けのサービスだけじゃなくて社内インフラにも関わりたい人、可用性の観点で他のクラウドも使ってマルチクラウドで今後開発をやってみたいと思っている方とかには非常に面白い内容なのではないかなと思いました。
おわりに
今回、連載4回目のインタビューとしてFJCTの通知システムの開発・運用の取り組みについて聞くことができました。
今後も様々なトピックスでニフクラのサービス品質を維持向上するための取り組みをエンジニアの現場視点でお届けしていきますので、ブログのチェックを是非よろしくお願いいたします！