LINEヤフー Advent Calendar 2023の19日目の記事です。
こんにちは。LINEヤフーの久慈泰範です。Advent Calendarは入社すぐに書いて以来、5年ぶりです。久々だー。
今日は、LINE（現 LINEヤフー） で SSL/TLS 証明書の購買を自動化した話を書きます。(以下、証明書と呼びます) 自動化のためにはタスクの形や人の動きを変えなければいけないことが多く、ほとんどの時間は混乱なく変化を続けていく方法を模索し続けていた時間だったように思います。2023年10月をもってやりたかったことは一通り終わったので、節目の記録としてこの記事を書くことにします。
- この記事に書いてあること
- 自動化のためにやった プロジェクトの概要
- 助けてくれたたくさんの方への感謝
- この記事に書いていないこと
- プログラムコードなど、技術的な話
Summary
LINEには多数のサービスがあり、500を超えるドメインが運用されています。サブドメインを含めると約十万件あります。LINEのサービスが増える時、それらドメインの証明書を用意しているのが我々です。月に数件だった申請は、LINEの成長とともに膨れ上がり、月に数百件を超えるタスクとなりました。
SSL購買プロジェクトの主なタスクは、審査が終わった証明書の申請を受けて内容確認、購買をし、ダウンロードに必要な権限を付与することです。最後にその申請を承認して一つの作業が終わります。これは 2022 年のreportですが、複数のフェーズを経て人間が動く時間を 2 年で 86% 減らすことに成功しました。現在はさらに自動化が進められており、受け取る申請の90%以上は我々の作業時間ゼロ！で処理されるようになっています。
Phase 0: Background
2019年、証明書の購買業務が私の部署に委譲されてきました。当初は流れ作業ということで渡された手順を元に対応していましたが、いくつかの問題が表面化してきたようです。私はそのプロジェクトの改善を任され、リードとして以降 3 年半、優秀なメンバーと共に様々な改善をしてきました。プロジェクトに参加した私は、まずは既存の作業を教えてもらい、実践しながら問題点を洗い出していきました。そこで感じたことがいくつかありました。
- 作業量が多すぎる。
- 提供までのリードタイムが長い。
- 作業漏れが日常茶飯事。
一言で言うとオールドスタイルな作業内容でした。LINEではもちろん様々な部署が自動化をしていますが、証明書の購買は事務作業に近かったためか、社内だけの問題のためか、歴史的な背景もあり取り残されていたようでした。
これを改善する日々が始まることになります。
Phase 1: 安心して自動化できる環境を整える
作業を細分化する
作業一つ一つを見ると、誰もが一目で「これ自動化できるじゃん」と思うような状態でした。私は見えるところから手をつけようとしていましたが、当時のマネージャーからまず作業の分析レポートを出すように求められます。あまり乗り気ではありませんでしたが、レポートを見た彼はタスクごとの工数を元に優先度をつけて進めるようにアドバイスをしてくれました。今思うとこれはとても重要な作業で、LINE STYLE(LINEの行動理念) にある “Always Data-driven” を実践した瞬間でした。彼の教えは今も大事にしています。
これは当時必要だった作業を表したグラフです。申請をスタート地点として作業が連なっています。この記事では、この作業全てを自動化していったプロセスを紹介します。
自動化の前にチームの地盤作り
作業内容をだいたい理解して改善を進めようとしていた頃、度重なる作業漏れが上層部からの苦情になったという声が届きました。画期的なことをする前に、まず目の前の問題を解決しなければいけません。これはあらゆる改善プロジェクトで壁になる部分で、当然私も「過去から続く運用を守り」つつ、「未来のための改善」を同時並行しなければいけなくなりました。
しかし、私はこのプロセスが大好きなんです。「上手に物事を変えていく」ことに情熱があるんです。燃えてきました。
当時の我々は放置されている申請も把握しておらず、スタッフ間のコミュニケーションも疎な状態で全員が同じ方向を向いているとは言えない状態でした。早く自動化をしたいという気持ちはありながらも、まず現状を把握することは Data Driven の第一歩です。
私はまず苦情がなくなる体制を目指すことにしました。やったことはとても単純で「当たり前でしょ」と言われるものばかりだと思いますが、地盤がない状態からではなかなかに大変で、優しく優秀なメンバーばかりだったからこそ成し遂げられたと思っています。当時の変更点は以下です。
As-Is
- 申請が来たら、これやってる人いますかー？と Slack で聞く
- 誰もやっていなさそうなら対応を開始する。ただし、「これやります」という宣言はしなくてもいい。
- 以降、その申請の処理状態はその人に一任される。
- 作業には待ち時間が多い。外部に依頼をして待つ→外部で滞る→そのまま忘れ去られてしまう事案が頻繁に発生。
To-Be
- 申請が来たら、Slack に申請名でスレッドを作る。
- そのスレッドを元に Jira ticket を作る。
- スレッドに reaction をつける
- 対応を開始した時
- 対応を完了した時
- 以降、週次ミーティングで close されていない Jira ticket の状況を追跡する。
- コミュニケーションは申請ごとにSlack thread内で行うことを徹底する。
Jira ticketを申請に対してではなく、Slack threadに対して作成することにしたのは2つの理由がありました。
- 当時、あるSlack channelへの問い合わせを Jira ticket にする bot を開発していたので使い回した
- コミュニケーションの分散が原因で起こったissueがあったので、制約をつけて情報が分散しないようにした。
これにより、対応が必要な申請が明確になり無駄なコミュニケーション、待ち時間も苦情も減りました。コミュニケーションを改善しただけで、積極的にやりたいメンバーが誰にも足を引っ張られずに作業を進めることができるようになりました。それに引っ張られて、他のメンバーも簡単な制約のもとで輝くようになっていきます。今までバラバラだった感じのチームは、たったこれだけの改善でも一つの方向を向くことができるようになりました。
LINE と言えばコミュニケーションツールですが、その使い方を少し変えるだけでも人の表情を変えることができる、コミュニケーションにはそんな魔法がある。そう思ったプロセスでした。
さらに申請の増加ペースがわかるようになったため、来年は倍の申請が来るので、自動化が急務であることもデータを持って確認することができました。
メンバーからの学び
誰かが決めた「手が空 いてる人が作業をする」というやり方を私は気に入っていたのですが、実際の現場では誰も手が空かない時間が発生してしまうものです。溜まった申請を前に頑張る人、見てみないふりをする人、反応は様々です。
メンバーから「チケットを自動でアサインするようにしよう」「当番制にしよう」といった案が出されました。強制的に仕事をアサインすると、義務感が発生するものです。それは仕事をつまらないものにしがちです。私はすご〜く嫌だったのですが、新しいアイデアはなんでもまずやってみることにしているので、渋々了承しました。
さらに申請を放置しないように、ルールが増えました。チケットがアサインされたら、24時間以内に内容を確認すること。１週間以内に完了すること。無理のない範囲ではありますが、だんだん狭苦しいプロジェクトになってきた気がします。うーん。大丈夫か？ これでみんな、楽しく仕事ができるか？
私の思いとは裏腹に、チームには活気が出ました。まず、責任分解点が明確になったため、作業数の大小への不平等がなくなり、不満がなくなりました。ルールという名のハードルをクリアするたびに、彼らは自信を持って作業を行えるようになっていきました。
さらに、自分たちの意見が採用され結果が出たので業務改善のアイデアが頻繁に出てくるようになりました。なるほど、自尊心も向上心もルールの元で育つのか。そんなことをメンバーから学びました。
Phase 2: 自動化するぞ！
苦情が出ない運用体制を作ることができ、やっと自動化に取り掛かれるようになりました。しかし、そこには 2 つ の大きな問題がありました。
1) 購買チームの作業を奪おう
我々が申請を受け取ってすることは、購買チームに証明書の購買を依頼することです。購買チームが大きな負担を背負っていて、彼らの仕事を待つことが我々の作業になっていました。この待ち時間によって我々の作業も完了を予測できず、場当たり的な対応が不可避になっていました。
これは大きな壁でしたが、マネージャーが購買作業を引き受けると言う大きな決断をして、購買チームに掛け合ってくれました。お金が動く作業ですから、流石に無理だろうと思ったらあっさり通りました。「その作業、うちでやります！」と言うのですから、購買チームも嬉しかったみたいです。
しかし当然、我々の作業は増えます。それでも自分でやった方が早い、コントロールできるようになる、という判断から行った大英断でした。この頃はまだ購買まで自動化できるとは具体的に考えていなかったように思います。単純に、もっと早く提供して苦情を減らすための施策だったように思います。まずは GlobalSign の Web 購買システムを操作する手順を書きながら、購買に必要なものを学んでいきました。
見積や稟議のプロセスも大幅に削減することができ、待ち時間が大幅に削減されました。結果的に、ミスが減りました。これは嬉しい副次効果でした。待ち時間の弊害が大きいことを学びました。
2) あなたのシステム、開発させて！
証明書の作業には大きく3つのシステムが関わっていました。
- 証明書の配布システム( Voyager )
- 申請プラットフォーム
- 申請のcallbackシステム（申請の承認をフックして自動的な処理を行う)
管理をしているのは社内クラウド Verda のメンバーでした。開発した後は他のプロジェクトに忙しく、bug の修正にも手が回りません。これまでも改善要望を何度も上げましたが、忙しさを理由に断られたり、代替策を提示されて終わっていました。自分たちで改善できればそんな交渉はしなくていいですし、我々もユーザも幸せになります。
一般的な会社ではシステムは部署に紐づいていると思いますが、やる気がある人がどこにでも飛び込んでいけるのが LINE の良さだったと思います。マネージャーの助けもあり、それらシステムの開発する権限を得ていきました。でもそれって、仕事が増えると言うことです。機能を追加したら、そのメンテナンスもしていかなくてはいけません。許可をしてくれただけでなく、一緒に依頼をしてくれたマネージャーには感謝しかありません。
Verdaの開発フローはとても新鮮でした。CI/CDは洗練されており、QA専門のメンバーもいます。LINEインフラの根幹を担う大規模開発の一端に触れることができました。
この頃、韓国、日本の旧セキュリティ室やトラフィックエンジニアリングチーム、運用チームなど様々な部署のメンバーを集めた Voyager team が発足します。証明書の配布システムとして中核になるシステム Voyager を中心に、LINEの証明書関連のポリシー策定や運用を行いま す。
一つの product のために、国境を越え、様々な部署の人と同じ方向を向いて議論ができるこのチームは最高でした。会議は通訳さんがいますが、wikiは全て英語、Slackも大体英語です。思い切ってメンバーに入れてもらったことは LINE に入社して以降、最も重要な判断だったと思います。Let’s encryptへの寄付に関わったのもいい思い出です。
全ての自動化は正規化から始まる
購買作業で我々を悩ましていたのは、ほぼフリーフォーマットな申請フォームでした。欲しいのはこの証明書でいいですか？ そんなやり取りが毎回発生していました。またもや無駄なコミュニケーションです。まずはそれをなくしましょう。各システムの開発環境を整え、手をつけていきました。フレームワーク特有の仕組みが全くわからず、右往左往しながらでしたがなんとかフォームを変え、Databaseにカラムを追加し、APIも変え、リリースしました。
その1年でやったことの大半は「機械が判断できるようにする」ことでした。人間同士が行うコミュニケーションを眺めて、何を抽出しようとしているのかを考えました。どんな情報がどんな形で database に入れば、何を自動化できるのかをずっと考えていました。databaseのカラムはどんどん追加され、テーブルも増えていきました。申請フォームの項目が洗練され、UI 上で auto complete や正規化がされるようになり、利用者も使いやすくなりました。typo で存在しないドメインの申請が来たり、common name に大文字と小文字が混在してた、なんて問題もなくなりました。
当初の作業分析で最も優先度が高いとされたのが、証明書 のダウンロードをする権限を申請された時の処理です。この日増しに増える申請は70%以上の作業を占めており、あと数ヶ月で我々のキャパシティを越えることが簡単に予想できていました。私は関係者に必要な変更を説明し、承諾を得て、プロセスを大胆に変えていきました。正規化したおかげで、機械的に処理を判断することができるようになり、承認に関わる手作業を無くすことに成功しました。この効果は絶大で、月によっては作業量が 5% まで減るほどの結果を出すことができました。
Phase 3: 証明書の自動購買システム CIPS(Certificate Instant Purchase System)
機械が買えばミスが減る
証明書を自動で買えたらいいよねーという話をしつつも、実は私は実現性や効果に懐疑的で、違う改善を進めようとしていました。率先して動いてくれたのが小林さんです。彼はすごい勢いで GlobalSign さんから API を手にいれ、あっという間に PoC を完成させてくれました。これは私のモチベーションを大きく動かし、自動購買システム CIPS を開発する契機になりました。
私は自動購買の必要性を資料にして、上司らに開発の許可を求めました。開発が必要な理由は様々で、それをまとめて説明するのに苦労しました。私を最も大きく動かしたモチベーションは、人為的なミスを減らしたいと言うものでした。驚くなかれ、購入作業が障害を生むこともあります。
証明書を購入するには、「そのドメインを私が所有している」ことを CA に認めてもらわなければいけません。この認証方法にはいくつかの種類があり、我々は DNS-01 認証と呼ばれるものを利用しています。認証にあたって DNS レコードを編集する必要がありますが、その頃、編集してはいけない DNS レコードを誤って変更してしまうインシデントが発生しました。beta 用ドメインだったため重大な障害にはなりませんでしたが、その作業をしたメンバーはひどく落ち込みました。人間はミスをするものです。その手順が、仕組みが悪いのです。重要な作業は全部機械にやってもらうようにしましょう。幸い、社内クラウド Verda には DNS 用の API も提供されていました。これも必要性を説明して、権限を発行してもらいました。部署やサービスの垣根を超えて、必要なことならと親身になって考えてくれ、助けてくれる優秀な社員がたくさんいました。一般的な日本企業では乗り越えられないような壁が存在しない、そう思わせてくれる文化がここにはあります。
当時書いた資料からは、人間の心理的負担を減らすことを主眼にしていたのが見て取れます。
無事に企画が通ったあとは楽しい開発の時間です。山あり谷あり、慣れない API 仕様で多少難儀はしましたが無事 Launch できました。API の利用者自体が珍しいにも関わらずいつも親身になって的確なサポートをしてくださる GlobalSign さんには感謝しかありません。API も非常に安定していて、我々のサービスは高い SLA を保つことができています。本当にありがとうございます。
そういえば証明書の期限通知も当初は人間が手動でメールしていました。それも自動化してむっちゃ楽になりました。通知漏れがなくなったのが何より嬉しいことです。
購買が早すぎる弊害
ほどなくして、LINEの開発者は申請の承認からたった 5 分で証明書を手に入れることができるようになりました。必要な時間はほとんどが CA の発行処理と DNS の TTL 待ちです。
当初２週間が当たり前だった提供時間は即日が当たり前になりました。
作業者に必要な作業は例外処理だけになりました。作業が減ったことも嬉しいですが、それよりも事故が減ったことが嬉しいです。
証明書の発行に人手がいらなくなったので、例えば深夜でも無人で発行できるようになりました。深夜に緊急で証明書を発行できればトラブルを迅速に解決できる。そんなことを思って 24 時間 CIPS を稼働させていたら、夜間にも思ったより使われることがわかりました。CA の API 仕様で証明書の期限(notAfter) はあまり自由にコントロールできなかったので、深夜に期限が設定された証明書がいくつか発行されました。深夜のトラブルは避けたいものです。できるだけ平日の日中帯に期限を迎える 証明書が発行されるように、CIPS の稼働時間は調整されることになりました。
今までは人間が証明書の期限を調整していたんですね。全く気づきませんでした。人間の脳を機械が理解できる形に変換するところが自動化の最難関ポイントかつ楽しくもあるんですが、だからと言って機械ができることに振り回されては本末転倒ですね。人間と同じように機械も休んでいいのではないでしょうか。
終わりに
だいぶ長くなりましたが、以上でこのお話は終わりです。古めかしいプロセスを完全に自動化するのは満足感があります。しかし、自動化という変化は、人間の動きをも変化させてしまいます。どんな動物も変化を嫌うものなので、事前に変化の必要性を説明し、ロジカルに理解してもらわないと否定的な感想を抱かれてしまいます。この project はトータルで見て、本当にうまくいったと思います。やりたいことはやり尽くしてしまったような感もありましたが、最近では社内で使われているすべての証明書を可視化するダッシュボードが作られたり、進化を続けています。そして旧Yahoo! JAPANにはまた素晴らしいエンジニアがおり、システムがあり、LINEヤフーとなった今、さらなる楽しそうな機会が待っています。
このプロジェクトを通じて、部署を超えた様々な人と関わりました。度重なるプロセスの変化に文句を言わずついてきてくれたメンバーには特に感謝をしています。助けてもらうだけでなく、Voyager teamにいるからこそ、人を助けてあげられる機会もありました。私はブレインストーミングが好きなんですが、Voyager teamではいつでも自由にアイデアを出し合うことが できます。途方も無いようなアイデアでも否定をする人はいません。歴史的な経緯に囚われる人も、変化を恐れる人もいません。本当に最高の技術者コミュニティだと思います。
LINEヤフーとなり我々のプロジェクトも形を変えていくと思いますが、縦割りでは無い組織や助け合い発展していく LINE の文化は残しつつ、素晴らしいヤフーの文化と融合してより進化していければと思っています。今後とも LINEヤフーをぜひよろしくお願いいたします。
なお、私はたまに来る TLS Handshake 絡みの問い合わせが楽しみでしょうがありません。トラブルシュートが必要な際はぜひ @uturned0 までご連絡ください。
そうそう。プロフェッショナルTLS＆PKI 改題第2版 が先日発売されたのでみんなで読みましょう！
ではでは。