技術部ソリューションチームの @etsxxx , @mom0tomo です。
ソリューションチームは全社の課題をエンジニアリングによって解決することを目的に2024年に発足したチームです。現在はインフラグループと情報システムグループのメンバーによる兼務で運営しています。
今回はソリューションチームとしての初リリースとなったOSSのURLリダイレクトツール(以下、redirector)とその導入後の効果について紹介します。
背景
リブセンスではAtlassian Confluenceを社内Wikiとして長年に渡って利用しています。これまでは情報システムグループがConfluenceのサーバー版(つまり自前構築版)を自力で運用していましたが、販売されるライセンスの変更やリブセンスのオンプレ環境の撤去などを踏まえて、この冬にSaaS版に移行しました。
さて、SaaS版移行ではひとつ困ったことが起こりました。URLの変更です。
え、ドメインが変わるのは当たり前だろうって？
そうじゃないんです。移行によりコンテンツのIDが変わるため、URLのパス部分、コンテンツのID部分が変わったのです。
そして長らくのConfluence運用で、そのURL数は20万以上。「古いURLは書き換えてください」と言っても、その新旧変換だけでも困難です。ましてや旧Confluenceが見られるうちはともかく、旧URLだけの情報では新記事を見つけ出すのは困難です。だからといって、いつまでも古い環境を残しておくことはできません。
スマートなHTTPリダイレクトするしかねぇ。
Webエンジニアならそう考えるでしょう。それをやったという、捻りのない話です。
作ったもの
旧来のConfluenceは以下のようなURLで動作していました。
https://xxx.example.co.jp/confluence/pages/viewpage.action?pageId=12345678
そこにアクセスが来たらリダイレクト・・・と言いたいところですが、それは旧環境が撤去された後での設定です。
新環境へのデータ移行時にデータが壊れたり失われたりすることがありうるため、しばらくは移行前のデータの確認用に旧環境を残す必要がありました。
そのため、まずは xxxの部分を new に書き換えれば動作するリダイレクトを作ることにしました。ブラウザのURL欄でこう書き換えるのです。
https://xxx.example.co.jp/confluence/pages/viewpage.action?pageId=12345678
↓ 書き換えてアクセス ↓
https://new.example.co.jp/confluence/pages/viewpage.action?pageId=12345678
このURLにアクセスすると新環境の新しい記事ページにリダイレクトされるという作りにします。これなら旧環境と共存ができます。
リダイレクトツール(redirector)の作成
ここではリダイレクトツール『redirector』について説明します。
リダイレクトするだけのツールはネットにも野良リポジトリが見つかります。しかし、過去の記事でも触れていますが、シンプルなものほど自作してしまう方が、リスクが低くカスタムもしやすいため、取り回しが良いと考えています。
redirectorの開発言語選定
Go言語を採用しました。
やりたいことはURL変換なのでとてもシンプルで、ほとんどGoの標準ライブラリで賄うことができると判断したためです。
また、ビルドしたバイナリ単体でサーバー機能を提供できるため、一度ビルドしてしまえばほぼメンテフリーで運用できることがメリットになると考えました。
シンプルにGoが好きでGo v1.22で開発したかったという理由もあります。
開発を終えてみれば、狙い通り、短時間かつとても少ないコード量で実装できました。
設定ファイルについて
冒頭でURL数は20万以上と書きましたが、このツールを開発し始めたときにはその数は定かではありませんでした。ただ、記事数は1,000や2,000ではないことだけは確かでした。
Confluenceにはすごくざっくり分けて、3種のURLがあることは分かっていました。
- 記事IDをGETクエリに入れているURLのタイプ
- 記事タイトルをURLにしているタイプ
- 短縮URLのタイプ
これらを構造化して、JSON等で入力する方法も考えました。しかし、それではこのredirectorをConfluence特化の作りにすることになりかねません。
そのため、設定ファイルにはbefore/afterのとてもシンプルなCSV形式を採用しました。
いざ移行作業後に生成してもらったConfluenceの新旧URL対比表を見ると、10万は軽く超える記事数があり、扱いやすいフォーマットにしたことは正解だったと思います。
redirectorの設定ファイルはシンプルなCSV形式ですが、元となるファイルは新旧Confluenceの情報の対比(例えば新旧の記事ID、短縮URLなどが入っている)を記載したより複雑なCSVです。
元のCSVをredirectorで扱えるシンプルな形式に変換する際にはPythonで作ったパーサーを使いました。パーサーにかけた結果、リダイレクトルールは207,744ルールとなっています。20行ほどの簡易なパーサーですが、リダイレクトルールが多いため、差し替えが発生した際にも非常に役に立ちました。
そうやって生成された20万を超えるルールをCSVファイルに書くだけで、CSVファイルのサイズは50MBを超えています。
redirector開発で工夫した点
工夫、と言っても本当に些細なものです。
このredirectorではGETクエリをルールに記載できるようにしています。
Nginx等のHTTPサーバーでリダイレクトを書く時、通常はパスを基準にしてリダイレクトルールを設定するでしょう。しかし、ConfluenceのURLではpageId=xxxxxというGETクエリで記事を指定していることが多々あります。GETクエリへの対応なしには、リダイレクトが書けないのです。
誤解を恐れずに言えば、GETクエリは順序に意味がありません。
したがって、以下は同じリクエストだと取り扱うのが妥当だと言えます。
- ?a=1&b=2
- ?b=2&a=1
実際にはページネーションなど、その環境特有のGETクエリもあるので、ルールに記載のないGETクエリは無視したほうが親切だったりします。
したがって、以下は全部同じリダイレクトが行われる方が適切だったりするケースがあるわけです。
- ?a=1
- ?a=1&b=2
- ?b=2&a=1
- ?a=1&page=9
細かな説明は省きますが、優先度とクエリマッチ数で適切なリダイレクト先を選ぶロジックを入れています。
優先度というと賢そうな印象ですが、シンプルに、ルールが競合したら先に設定したものが勝つというものにしています。(つまりおかしなリダイレクトが発生したら、CSVの記述順序を入れ替えたら良い)
ロジックが雑なので計算量に無駄があることは気にしていますが、リダイレクトにパフォーマンスはそこまで必要ないため、ひとまずは問題なさそうです。
このツールは世の中の全てのリダイレクトのニーズに対応しているなんて驕ったことは全く言いませんが、redirectorはConfluence移行の我々のニーズには対応しました。
ニーズに合わせて必要なロジックを自在に組み込めるのは、ツールを自作するメリットです。(そもそも20万以上のルールが必要な時点で、マネージドサービスの選択肢は薄いのですがw)
リダイレクトサービス動作環境の構築
ホスティングはECSを使い、前段にALBを置きました。Goのビルド後のバイナリなのでEC2などでもホスティングは容易にできましたが、インスタンスの運用コストがかからないECSを選びました。
ECSとALBを利用した背景には、ここ数年でマッハバイトのサーバーをオンプレVMからECSへ、NginxからALBへ移行するプロジェクトが実施され、インフラグループ内で構築・運用の知見が溜まっていたことがあります。
Terraformで書かれたコードが既にあるため、コードの再利用によりスピード感を持って初期構築でき、また運用時に他のメンバーも扱いやすい状態になりました。
リリース後の反応
このリダイレクトサービスのリリースにあたって留意したのはスピード感です。旧URLから新URLへの変更は全社員に影響があるため、なるべく早い段階でサービスを提供することで多くの人の手間を省くことができます。
リリースにあたっては、ソリューションチームのメンバーがインフラグループとConfluence移行を担当した情報システムグループとで構成されていたおかげで話が早く進み、Confluence移行から数日でリリースすることができました。
リリースから数日後、非エンジニアがbookmarkletを作って共有してくれました。
また、Google拡張による自動リダイレクトに対応させる人が現れました。(拡張名は念のため伏せてます)
さらに、Chrome拡張のrequestlyで自動リダイレクトに対応する人も現れました。
利用方法が簡単なサービスを作ると、それを利用して新しいツールが生まれる、良いスパイラルが発生しているように思える流れでした。
終わりに
この記事では、技術部ソリューションチームが、社内WikiであるConfluenceの移行によって発生した新旧URLが変わってしまう問題に対処するためのリダイレクトサービスを作成し、リリースした話をしました。
情報システムグループ主導のConfluenceのSaaS移行プロジェクトは、実施までに4ヶ月を要した大きなプロジェクトでした。SaaS化によるメリットはたくさんありますが、その一方で発生する負の部分である「URLが異なる問題」に懸念の声があったことは事実です。しかし、簡単にサービスを立ち上げるナレッジを持ったソリューションチームが解決法を提示し、懸念を解消できたように思います。
リダイレクトサービスのリリース後、古いURLで困っているという声は殆ど聞かれません。これで安心してConfluence旧環境を停止することもできるでしょう。部署・チーム間の連携、そしてそのためのソリューションチームの初のサービスリリースの話をお伝えしました。
