このページの本文へ

混在コンテンツは運用も疲弊するのでやるなら一気に!

さくらインターネットに常時SSL化移行の体験談を聞いた

2018年01月09日 07時00分更新

文● 大谷イビサ/TECH.ASCII.jp 写真●曽根田元

提供: さくらインターネット

  • この記事をはてなブックマークに追加
  • 本文印刷

商用のSSLサーバー証明書に加え、無料の「Let's Encrypt」も積極的に推進しているさくらインターネットは自社サイトの常時SSL化も進めている(関連記事:「常時SSL」はなぜ必要? さくらインターネットがQ&Aで答える)。ここでは常時SSL化を進めるに当たってのノウハウや苦労話を共有してもらうことにした。(以下、敬称略 インタビュアー アスキー編集部 大谷イビサ)

さくらインターネット セールスマーケティング本部 マーケティング部 天内雅晴氏、技術本部 アプリケーショングループ 池添正隆、技術本部 アプリケーショングループ 山田望氏

常時SSL化を機にサーバーもすべてクラウドへ

大谷:まずは今回常時SSLに移行したさくらインターネットのサイト構成について教えてください。

山田:さくらインターネットは、トップページにあたる公式サイトやサービスごとのサービスサイト、オウンドメディア、情報共有など、さまざまなサイトを運営しています。WordPressで運営してたり、他サイトから情報を引っ張ってくるみたいなサイトもあります。いずれにせよ、20周年を迎えたインターネット企業なので、かなりのサイト数があります。

大谷:システム的にはどんな感じなんでしょうか?

池添:サイトは大きくユーザーから見て前段にあたるプロキシサーバーと後段のコンテンツサーバーで構成されています。リクエストはNginxのリバースプロキシから冗長化されたコンテンツサーバーに振り分けられます。コンテンツサーバーでは複数サイトを同居させています。

大谷:サイトのSSL化はどんな感じに進んだのでしょうか?

山田:正直、サイト全体がSSLというサイトは長らく存在せず、問い合わせや申し込みなどお客様が情報を入力するフォームにSSLがかかっていただけでした。しかし、SSLサーバー証明書のサービスサイトはさすがにSSL化したほうがいいだろうという話で、一番早くサイト全体をSSL化しました。その後、常時SSLやらなければという話はあったのですが、サイトの数が多かったので徐々に対応していきました。

池添:2016年からはトップページやサービスサイトのSSL化も進め、現在はグローバルメニューのリンクはすべてHTTPS化済みです。また、以前はすべて物理サーバーだったので、常時SSL化を機にさくらのクラウドに移行しつつあります。

「常時SSL化を機にさくらのクラウドに移行しつつあります」(池添氏)

大谷:プロジェクトの承認を通すのは大変だったでしょうか?

天内:うちの場合はそれほど大変ではなかったですが、Webプロデューサーがデザイン系やビジネス系の方だと、重要性を理解してもらえず、承認を通すのは大変かもしれません。うちの場合、ほかの案件が混んでいたため、多少後倒しになった感じです。

大谷:運用体制は変更したりしたんでしょうか?

天内:過去はいろいろな部門で管理が分かれていたので、期限切れで更新されないというリスクもありました。管理が個人にひもづくと、メールの見逃しなどもありますし。今回の常時SSL化を機にそこらへんも、SSLサーバーの事業部に統合することにしました。

「常時SSL化を機に管理もSSLサーバーの事業部に統合することにしました」(天内氏)

混在コンテンツは運用が一番つらい

大谷:移行作業はなにか苦労はあったのでしょうか?

山田:HTTPで運用していたサイトが、すべてHTTPSになるので、コンテンツのリンク修正が大変でした。運営しているサイトのリンクを書き換えつつ、漏れがあるといけないので、リダイレクト設定をかけています。

大谷:スクリプトで一気にみたいな感じだったんですかね。

山田:確かにgrepで洗い出しはするんですけど、最終的にはけっこう目視でチェックしましたね。コード管理をきちんとやり始めたのも、ここ数年のことだし、歴史的に古いサイトも多いし、URLの置換作業をやっていたときに、これちゃんと動くのかみたいな不安もありましたね。たとえば、AjaxでHTTPサイトの情報を引っ張っている場合は、そのリンクを画像の中に埋め込んでしまいますので、HTTPとHTTPSの混在コンテンツになってしまいます。混在コンテンツが一番運用がつらいです。

大谷:コンテンツのバージョンアップに加え、サーバーの切り替えはどうでしたか?

池添:切り替えはややトリッキーでした。単に古いコンテンツに新しいコンテンツを上書きすると、プロキシ側で表示できない期間ができてしまいます。そのため、背後にある4台のコンテンツサーバーに新しいコンテンツと古いコンテンツを半分ずつ入れておき、新しいHTTPSのサーバーを参照するよう、リバースプロキシ側のupstream設定を書き換えるみたいな移行をやりました。

大谷:こちらはスムーズだったんでしょうかね。

山田:そうでもなかったです(笑)。サービスサイトのトップページでさくらの20周年コンテンツを入れることにしたとき、外部から情報を取得するJavaScriptを書いてたのですが、開発やステージングをHTTPにしていたため、リリースしたらHTTPSサイトが表示できないというエラーが出ました。20周年パーティで20周年サイトをオープンするという催しで切り替わらないという痛い感じでした。

オウンドメディアのさくらのナレッジでも、HTTPSサイトにリダイレクトされているけど、コンテンツがHTTP化されておらず、ページが表示できないということもありました。もう混在コンテンツは見たくないですね(笑)。

「もう混在コンテンツは見たくないですね(笑)」(山田氏)

証明書はコストと信頼性で使い分ける

大谷:常時SSLで使う証明書はなにをお使いですか?

山田:オフィシャルサイトやサービスサイトではサイバートラストのEV SSL証明書を使っています。開発環境は無料のSSLサーバー証明書であるLet's Encryptを使っています。

大谷:本番がHTTPSになるので、開発もHTTPSで確認する必要があるんですね。

池添:開発環境はGitHubにコードをコミットすると、Dockerがデプロイされて、Webサーバーが立ち上がるみたいな構成になっています。使う人は5~6人ですが、コンテナとしては20~30近く立ち上がることになります。全部に商用の証明書を入れるのは大変なので、Let's Encyrptを使っています。

ただ、Let's Encyrptって仕様上、同じドメインで発行できる枚数が決まっているんです。現状はその上限に引っかかってしまうので、数を絞って使っています。ただ、来年からはワイルドカード証明書の発行が可能になるので、基本的にはこちらの望んだ環境になるはずです。

大谷:常時SSL化するとコストは上がりますか?

天内:基本はEV SSLですし、うちの場合はサブドメインが多い運用なので上がりますね。とはいえ、開発環境はLet's Encryptですし、オウンドメディアなどにはちょっと安めの証明書を使っています。

大谷:性能が遅くなるとか、そういったことはありましたか?

山田:移行にあわせてサーバーも新しくしているので、性能面でのペナルティはないですね。SSLのオフロードとかそういったこともやってないです。

「サーバーも新しくしているので、性能面でのペナルティはないですね」(山田氏)

大谷:最後に今後常時SSL化を検討している読者に一言お願いします。

山田:やはりHTTPとHTTPSの両方だと運用がつらいので、やるなら一気にやってしまったほうがよいです。繰り返しですが、混在コンテンツはもう見たくないです(笑)。

■関連サイト

(提供:さくらインターネット)

カテゴリートップへ

灯油タンクで残量検知を実現!北海道の生活を守るIoTとは【熱量IoT】#3

動画一覧はこちら!