ホスティング事業部の CTL(Chief Technical Lead)の@pyamaです。本記事では先日盛大にリリースいたしましたロリポップの無料独自SSL機能の裏側について関わったメンバーのリレー形式で紹介したいと思います。
Let's Encrypt提供の背景
ロリポップ！のディレクターをしています@fuchinoです。ロリポップ！のリブランディングプロジェクトやプロモーション、プロダクト周り、イベントなどを担当する、ディレクターという名の何でも屋です。
Let's Encrypt提供の背景について、少し書かせていただきます。
2014年ごろから、急激に独自SSLの需要が増加しました。Googleが常時SSL化への取り組みを強化し、推奨したことが大きな理由です。2016年、Let's Encryptが正式に提供開始されてからは、その流れは一気に加速します。
ロリポップ！では、もともと有料の独自SSLオプションは提供していましたが、日に日にLet's Encrypt取り扱いについてのご要望が多く寄せられるようになります。
私たちは国内でも有数のユーザーを抱える、巨大なレンタルサーバーサービスです。このタイミングで、単なるマーケティング的な戦略だけでなく、日本のインターネットの健全な発展に責任ある立場として、すべてのユーザーが常時SSL化によるメリットを享受すべきと判断しました。
この判断が下ったその日には、Let's Encrypt取り扱いに向けた開発がすぐにスタートしました。決定から2ヶ月ほどでリリースまで完了していますので、非常にスピードある対応だったと思います。
Let's Encryptへの支援について
Let's Encryptを運営するInternet Security Research Group（ISRG）は、非営利の公益法人です。公共性の高い団体が提供するサービスですから、私たち営利企業が「タダ乗り」するのは避けたいと考えています。
ロリポップ！を始めとする、GMOペパボのサービスは、多数のOSSなど、無償の貢献による技術を利用し成り立っています。
そのため、弊社ではエンジニアのOSS活動が推奨され、「利用する分以上に貢献する」文化が、強制されることなく自然と出来上がっています。
ISRGに対しても、今回の機能提供に先立ち寄付を実施しています。これも誰が言い出すわけでもなく、自然な流れであっさり決まってしまいました。
今後も寄付等による貢献はもちろん継続していきます。さらには、ISRGスポンサー実現に向けて「がんばるぞ！」の気持ちを高めています。
アーキテクチャ
どうも、お久しぶりです @pyama です。 今回のロリポップの無料SSL証明書は以下の図のようなアーキテクチャで実現しました。それぞれのロールについて簡単に紹介します。
ユーザー専用ページ
ユーザー専用ページが今回の無料SSLサービスの入り口になっており、お客様がこの画面で任意の独自ドメインに設定を行うことで、証明書の発行を行っています。
Let'sEncryptには証明書発行に際し、いくつかのレートリミットが存在するため、その制約をUIに落とし込みつつも、最小限の操作で証明書の発行が出来るように工夫しています。UI/UXの設計については後日もう少し詳しく記事にしたいと思いますので、ご期待下さい！
Golang Echo
今回はGolangのAPIフレームワーク、Echoを採用しました。
これまでロリポップではPerlで実装されたJSON RPCベースのAPIを利用していたのですが、無料SSL証明書サービスの提供に合わせてRESTfulな設計、更には静的型付け言語であるGolangへと大きな方針転換を行いました。
Golangを採用した理由としては我々がビジネスを行っているホスティングの領域では、サーバインフラが商材であり、そのオペレーションツールの開発におけるシステムコールの扱いやすさや、可搬性の高さに魅力を感じたことが大きな理由です。
Echoについては、フルスタックフレームワークである、Revelと比較し、Echoがフレームワークとしての実装が薄く、ミドルウェアの拡張が容易であることに魅力を感じ、採用しました。Revelについては確かに色々やれることが多いのですが、我々のやりたいことに対して少しオーバースペックであったことが見送りとなった理由です。
またGolangへの技術シフトを考えるとフレームワークの学習コストはなるべく下げたいという意図があったため、フレームワークが薄いということは一つの重要な指標でした。
一方でEchoはまだまだ開発が活発であることからバージョンアップの度に、後方互換が失われることが多く、その点については少々苦労していますが、Echo自体がかなりテストを書きやすいこともあり、テストカバレッジが高い状態で開発できているので、本番でのデグレードなどは今のところ起きていません。
Echoと組み合わせて使用するORMにはgormを採用しています。PreloadやAssociationの記法など、同じことやるのに複数のやり方があるというのがあまりGolangっぽくないなと感じてはいるものの、ORMはなるべくシンプルなものを使いたかったこともあり、gormを採用しています。ドキュメントが整備されているので基本的なことはドキュメントを読めば分かりますし、痒いところもドキュメントがないだけで、コールバック的にかけることも多いので、ソースを読みながら運用できるのであれば、かなり有力な選択肢になると思います。
Ruby Sidekiq(ACME-JOB)
このパートは @atani が担当します。 Golang EchoにSSL証明書の発行がリクエストされると、Ruby製のジョブワーカーSidekiqに証明書の発行をエンキューします。
ジョブにおいてはacme-clientを利用し、クライアントの登録や、ドメイン認証を行っています。ドメイン認証においてはロリポップ！のようにお客様が自由にAレコードを変更できる場合、該当のドメインのAレコードがロリポップ！のIPを指していないケースも有るため、事前のバリデーションで工夫しています。
発行された証明書はデータベースにEcho経由で登録を行い、 ロリポップ！のプロキシサーバで利用しているngx_mrubyによって動的に読み込まれ、HTTPS通信が利用可能になります。
またロリポップ！においてはHTTP/2に対応済みなので、無料SSL証明書を利用することでサイトの高速表示が可能になります。
協業について
こんにちは、いよいよ夏本番ですね。 @pyama です。 本機能の開発においてはCloudInfra Podcastやknife zeroの作者として知られるHiganWorks LLCの@sawanoboly氏との協業によって実現しております。特に前述のACMEのジョブサーバにおいては尽力頂きました。
ホスティング事業部ではこれまで社外のエンジニアとリモートワークでの協業という経験は少なかったのですが、今回の取り組みが非常に良いものであったため、今後、同じような取り組みを増やしていきたいと考えています。
@sawanoboly氏よりコメント:
今回縁があって本件のお手伝いをしました。無事リリースされ喜ばしく思います。
本文中にもあるように、期間2ヶ月と一見タイトな開発でしたが、以前よりいくらか親交のあったGMOペパボ社の誇るイケメンマエストロ@pyama氏を筆頭に、福岡天神のイケメンエンジニア勢(注:対応がイケメン・構築がイケメンなどの部分イケメンを含みます。)がシュッとしているために、わりと余裕を持って開発できました。
ついでにACMEジョブサーバの話をしますと、証明書の発行関連では申請・適用といった複数のステップにそれぞれ専用のモジュールと、通知など運用系のモジュールががあり、どこからリトライするかの考慮をした結果、当初の想定よりワーカーが細かく分かれていった事が印象に残っています。
なお本件の開発中、主に制限事項に関して得た知見は次のリンクで公開しています。わずかばかりですが、大量導入が必要なケースでの助けとなれば幸いです。
そういえば(当然ですが)証明書は自動更新なんですよね？ 10月を楽しみに待ちましょう！
まとめ
今回、無料SSLを実現したアーキテクチャ含めてご紹介しました。今後HTTPSが標準となっていくであろう昨今において、このタイミングでお客様に機能提供が出来たのは本当に良かったなと思っています。 さらには無料SSLだけではなく、続く新機能、新プランを予定しておりますので、楽しみにお待ちいただければと思います。
最後に、僕たちは今後もよりお客様に満足いただけるサービスを目指して、研鑽し、取り組んで行きますので、ぜひご期待ください。