auカブコム証券がGoogle発SREで変わったこと

第5回 auカブコムがSREで変わったこと~前編~

 auカブコムSREが発足するまでのエピソードをご紹介した第3回、第4回の記事掲載が終わり、残り2回の連載では2020年度の1年間のSREの取り組みとその改善効果をご紹介していきます。
 auカブコムSREのミッションは「運用の高度化は継続しつつも、よりお客さまサービス目線での運用改善・拡大に切り込んでいくこと」です。そのため、2020年度のSREグループの年間ロードマップの施策には、運用改善という従来の施策に加えて、お客さま目線でサービス改善につながる取り組みを3項目追加しました。「重要システムのKPI設定と閾値監視の高度化」「インシデント発生時の早期解決に向けたPD(Problem Determination)推進」「お客さまのご要望の早期実現・苦情の早期改善」です。今回の記事では以下の2つの取り組みについてご紹介します。
 ・重要システムのKPI設定と閾値監視の高度化
 ・インシデント発生時の早期解決に向けたPD推進

目次
●証券取引システムの運用
●キャパシティ管理の必要性
●重要システムのKPI設定と閾値監視
●SLOでみえてきた次のアクションプラン
●システムインシデントが発生した場合の早期解決
●まとめ

●証券取引システムの運用

 ロードマップの取り組みと効果をご紹介する前に、少し証券取引システムの概要について説明させていただきます。
 証券取引システムは大きく分けて「フロントシステム」と「バックシステム」があります。フロントシステムは、お客さまの注文を受け、取引所への発注の後に約定結果をお客さまマイページに反映する約定システムや、投資情報・マーケットニュース・株価チャートを表示する情報システムなど、ユーザが直接使用するシステムの総称です。バックシステムは、証券口座を管理するシステムの総称で、お客さまの個人情報管理・精算管理を行っています。また、証券保管振替機構や金融機関などの外部機関と連携を行い、日々お客さま資産の管理をしています。
 ネット証券では、お客さまに様々な発注サービスや投資分析ツールを提供していますが、マーケットでは市場状況が常に変動しており、1分1秒の投資判断が時には大きな損益に影響するため、システムには常に高度な可用性が求められています。

 

●キャパシティ管理の必要性

 高度な可用性を実現するためには各システムのキャパシティ管理が必要です。マーケットの変化によって相場が大きく動くと、お客さまの取引が活発となり、一気に取引量が増え、システム負荷が高くなるケースがあります。例えば、2020年の新型コロナ感染症の拡大も大きく相場に影響しました。実際に起こったシステム障害をご紹介します。
 2020年2月25日、新型コロナウイルスの感染が世界各地に飛び火し、景気・企業業績悪化に対する不安が高まり、東京株式市場で日経平均株価は大幅下落しました。
 一時1000円超下げるなどパニック相場となり、2020年10月以来約4カ月ぶりの安値で取引を終えています。情勢の変化により大きくマーケットが動いた当日の朝、当社オンライントレードツール「kabuステーション®」にて、朝9:00の寄り付き時間帯に、短時間に許容量を超えるチャートリクエストを受信。チャート表示サーバが負荷に耐えられなくなり、画面表示が遅延する事象が発生しました。即時対応として予備サーバを稼働させ、事象の復旧を行いましたが、この障害により、従来のシステムキャパシティでは相場の変動によるシステムニーズに対応できないことが分かりました。(本事象に対しては、常設サーバの増設、各種閾値の見直しにより再発防止を行っています)
 改めて「キャパシティ管理の重要性」が問われたのです。当時、2019年12月に「auカブコム証券」に生まれ変わった当社は、KDDIグループもつ顧客基盤を取り込み、更なる口座数獲得を目指していたため、より一層「未来のシステムニーズに耐えうるシステムキャパシティ管理」をすることが重要となりました。

 

●重要システムのKPI設定と閾値監視

 キャパシティ管理の課題が浮き彫りになり、改めて当社重要システムの正常稼働を担保する指標を定めて計測することを行いました。証券取引を行っていただくうえで、お客さま目線で重要となるシステムフローの洗い出しを行いました。具体的には、重要な指標を6つに分類し、各項目のKPI設定を目指しました。今回は6つの指標の中でも「入金サービス」に関する取り組みとその成果をご紹介します。

入金サービス
 株取引を始めるには、あらかじめ株を購入するために必要となる資金を当社の口座に預けていただく必要があります。取引を始めるにあたって最初のアクションとなるため、オンライントレードではスムーズに入金できることが重要となります。
 当社では5種類の入金サービスを用意しており、ATMやインターネットバンキングを利用して当社口座へお振り込みいただく方法や、自動引き落としサービスとしてマイページ上で事前にご登録いただいたお客さまの銀行口座から自動的に入金するサービスがあります。

 入金する上で、「お客さま入力完了」から「入出金確認画面表示」までの所要時間は短いほど、リアルタイムに操作できているといえます。しかし度々、入金反映に時間を要しているというお問い合わせが来ることもあり、私たちは、実際に当社のサービスはどのくらいの処理時間を要しているのかを把握し、その時間はどのような外的要因によって変動するのか、を分析できる状態にすることが重要だと考えました。そのため、入金サービス完了の所要時間をSLIとして計測することを決めました。

 最初に行ったのは、データフロー図の作成です。データをどこで取得する必要があるか整理するため、システム構成図の中で各プロセスにおけるデータの流れを視覚的に表現しました。最初にデータフローを図にすることで処理時間の計測イメージが付きやすくなりました。

 次にログ分析を行いました。ログの集約・分析にはSplunk社の「Splunk Enterprise®」を使用しました。Splunk Enterprise®は統合ログ解析・管理ツールで、ソースやフォーマットを問わず様々なデータの分析が可能になっています。分析した結果はダッシュボードでカスタマイズして可視化でき、目的に沿ったデータの見せ方ができます。
 当社ではセキュリティ管理として2020年以前よりSplunk社の製品を導入しておりましたが、SREメンバーのほとんどは実務で触れたことが無かったため、Splunk社のご協力により社内ハンズオン研修を開催していただき、使用方法に対する基礎理解を深めました。研修の中ではツールを利用したダッシュボードの可視化の例や、実際に他社での利活用例を紹介いただき、よりイメージが付きやすく、実現しようとしている目標値(SLO)策定に向けて様々な利活用ができると感じました。

 

●SLOでみえてきた次のアクションプラン

 Splunk Enterprise®で分析したデータから、入金サービスのSLIの傾向分析・キャパシティ把握を行ったところ、ほとんどの入金では「お客さま入力完了」から「入出金確認画面表示」までの所要時間が60秒以内である一方で、ある特定の時間帯では処理に120秒~600秒という時間がかかっていることが分かりました。調査をしたところ、同時間帯に同じ処理フローで動いている別のシステムプロセスがボトルネックとなっていたことがわかりました。この結果を受け、特定の時間を除外した所要時間の目標値SLO=「60秒以内の所要時間である入金が90%以上であること」とシステム部内で定義し、SLOを下回る時間帯に関しては、予めお客さまへの適切な周知などの措置が必要であると確認しました。
 システム部内で決めたSLOを全社周知する前に、まず調査結果とSLOを下回る時間帯に関するお客さま周知の提案を、営業部門と協議しました。適切な事前周知をすることで、処理に時間のかかる時間帯を避けてのサービス利用を促すことができ、効果的であるという結論になりました。つまり、次のアクションプラン=「顧客への適切なサービス周知」に繋げることができたのです。

図 Splunk Enterprise®のダッシュボードでの分析結果
あるサービスに関する入金件数推移(折れ線グラフ)と処理時間ごとの割合(円グラフ)

 活動開始当初は何をKPIとすべきかという議論からスタートしましたが、2020年度1年間の活動継続で、入金サービスへの所要時間についてのSLOを定め、ボトルネックを特定し、お客さまへの周知方法を検討するという段階まで到達しました。
 他の重要指標に関しても同様のサイクルで取り組むことで、キャパシティの把握、ユーザビリティの向上に向けた改善を重ねていくことが2021年度のSREグループの施策となっています。

 

●システムインシデントが発生した場合の早期解決

 「重要システムのKPI設定と閾値監視」に加え、2020年度SREでは、インシデント発生時の早期解決に向けたPD(Problem Determination)の仕組みづくりと推進を行いました。システム障害発生時に求められることは、早期の課題特定、適切なお客さま告知、そして早期の障害復旧です。当社では2020年以前よりメール・対面ベースでのPDによって情報の集約や対応指示が行われていましたが、2020年の緊急事態宣言によって、テレワーク中心の働き方に変わったことで、会議室に集まって話し合うコミュニケーションの取り方が難しくなりました。社員の約8割はテレワークとなり、自然と対面での会話からチャットベースでの会話へシフトしていったのです。この流れを受けて、チャットツールを活用したPDの推進が必要となりました。
 「目的」は以前のまま、チャットツールを利用した「進め方」のルール作りを行い、障害発生時のフローを平準化、社内に浸透させていきました。

・目的
■ 障害検知から、社内連携までの速度向上
 → お客さま告知までの速度も向上し、障害対応状況を迅速に伝える
■ 障害復旧までの速度向上
 → 障害調査・対応者(開発)と、情報集約・連携(SRE)の役割を分離する
■ SREグループの障害対応力強化
 → SREグループにとって新しい取り組みであるため、全メンバーが積極的に活動できるようにする。障害対応活動を通して、業務知識を習得する。

・進め方
1.PDの運用構築・周知
2.障害対応体制・役割の構築
   →役割を主(旗振り)、副(サポート)に分割
3.障害対応手順のマニュアル化
   →主・副各々が、いつ何のためにどのように行動するか定義
4.ロールプレイング
   →SRE内での擬似行動、障害訓練(他部門も参加)
5.実践

 実践をしていくと、チャットツールでは事象別に部屋を作成(部屋の名前を事象名にする)することで、どこの部屋を見に行けばどの障害の情報に到達できるかが分かりやすくなりました。また、部屋の中ですぐにリモート会議が設定できるため、より柔軟で迅速な情報集約が可能になりました。社内連携を迅速化することができ、SREがシステム部門と他部門のハブとなって情報を集約するというフローを定着化することができました。

 

●まとめ

 今回は、2020年度のauカブコムの年間施策のうち「重要システムのKPI設定と閾値監視の高度化」と「インシデント発生時の早期解決に向けたPDの仕組みづくり」についてご説明しました。
 いずれもお客さまに提供しているサービスの正常性、可用性を維持する上で重要だと考え、変化し続ける外的環境にどう適応していくか、ということを考えてきました。
 2020年度の活動実績としてKPI施策では、SLOの策定によって、お客さまに向けて周知すべき内容が見え、改善アクションへと結びつけることができました。
 また、インシデント発生時の早期解決に向けたPDの仕組みづくりでは、メール・対面でのコミュニケーション中心だった以前よりもチャットツールベースでの柔軟なやりとりによって各段に問題特定→解決に向けたスピードアップを実現できました。

 次回は、auカブコムSREの取り組みをさらにご紹介します。そしてコラム最終回としてタイトル通り「auカブコム証券がGoogle発SREで変わったこと」の総括を行います。最終回もよろしくお願いします。

 

   auカブコム証券では一緒に働く仲間を募集しています。
   当社に少しでもご興味をもった方がいましたら、ぜひ当社で一緒に働いてみませんか?

   採用についてはこちら
   auカブコム証券株式会社の会社情報 (Wantedly)
   https://www.wantedly.com/companies/kabu2

 

連載一覧

コメント

筆者紹介

道場大(みちばだい)
2011年FX専業の会社に入社し、金融業界に進出。システム担当として各種サービスの設計、構築、保守、運用に広く携わる他、お客様対応、当局対応にも深く関わり、2015年にシステム責任者に就任。対顧サービス完全クラウド化など、多岐に渡る主要プロジェクトを歴任。
2019年スキル拡張を目的とし、auカブコム証券に転職。初年度実績を評価され、本年4月より技術部SREグループ長に就任。チームビルディングの傍ら、auカブコム流SREを体現。SREロードマップ実現に向けて邁進。

太田有美(おおたゆみ)
2016年auカブコム証券会社に新卒入社。2017年よりシステムインフラ部署でサーバ設計構築を担当。2020年4月に新体制であるSREグループ発足により、初期SREメンバーとして活動。旧運用チーム時代から新SREグループ誕生の過程で運用高度化を実感した経験を生かし、当社の体験をコラムでわかりやすくお伝えできるよう邁進中。

バックナンバー