我社のGot Shifterまでの道のり

こんにちは。おーさかです。

Shifterの2020年のアドベントカレンダーに投稿するためにnoteを始めてみました。何事も「ものは試し」ということで。（このエディタ、シンプル過ぎて書きづらいw）

ここではおーさかの所属する株式会社エクレクトがコーポレートサイトを今年の11月にShifterに切り替えるまでの経緯、クリアしなければいけなかった課題や反省点を振り返ろうと思います。内容は2020/12/2に開催されたShifterオンラインミートアップ「Shifter 大忘年会 2020」のLTのリライトですが、録画にも関わらず酔っ払っていて、それ故にぐだぐたオーバーランしたので、ここには真面目（気味）にまとめたいと思います。今後Shifterでサイトを公開される方の何かの参考になれば。

コーポレートサイトリニューアルの経緯

Shifterに切り替える前までは、2017年の創業時にとりあえずで作られたベタ書き1ページのコーポレートサイトと、ノリでZendesk Guideで作られたサービスサイトの2つが別々のドメインで公開されている状態でした。ちなみにZendesk Guideは、FAQサイトの公開に特化したシンプルなCMSです。テンプレートのカスタマイズが結構柔軟にできるので、FAQサイト公開以外用途でも使えないこともないのですが、運用していると細かいところであれやこれやと無理が生じてきます。弊社のサービスサイトも例に漏れず、「やっぱりこれマーケ目的だと運用しづらいよね...例えばOGP設定できないとか...」となっていました（とはいえ、「Zendesk Guideでここまでできるんやで！どないや！すごいやろ！」サイトとしての価値はあるので、検索エンジンに引っかからないようにして今も残してますw）。それに加えて、別々のドメインで公開されているコーポレートサイトとサービスサイトがどうも重複コンテンツ判定されていたようで検索上位に上がって来ない疑惑も浮上しておりました。そんなこんなで、弊社敏腕マーケがその2つのサイトのコンテンツをまとめた新コーポレートサイトリニューアルを宣言したのが、2019年の夏頃だったかな？その当時はおーさかは、「へ〜！いいね〜！頑張ってくださ〜い！」とプロジェクトの外側から高みの見物を決め込んでおりました。

なぜShifterを使うことになったのか？

おーさかはどちらかというとインフラ寄りの技術が好きなため、あまりWebサイト運営とかCMSのことは詳しくありません。が、なぜか2020年1月からShifter Meetupにお邪魔するようになり、流れでLTまですることに...という経緯もあってShifterを本格活用したい欲望が芽生えておりました。とはいえやっていたことは、具体的な戦略もないままただただ雑談レベルで社内の人にたま〜にShifterを紹介してたぐらいです。

2020年9月頃に弊社敏腕マーケから急に「例の新しいコーポレートサイト、WordPressであれするやけど、おーさかさんが前に言うてたあれなんやっけ？」という伝わる人にしか伝わらない質問が飛んで来ました。なんやかんやあってしばらく凍結されていたコーポレートサイトリニューアルプロジェクトが再稼働。管理機能やプラグインが充実してて、使い慣れているWordPressを採用したいけど、そういやインフラどうしようか？という相談でした。おーさかにとってはShifter使いたい欲を満たすための絶好のチャンスなので、即座に便乗。利用必須プラグインのAll in One SEOもShifterで動くことも分かったので、敏腕マーケと結託して社内調整を開始します。最終社長稟議は「Shifterなら、しゃちょーがNHKに出ようが、情熱大陸に出ようが耐えられるサイトにできますよ！」の一言でOKが出ました。

真面目に選定理由を列挙するとこんな感じ

・マーケ担当が慣れているWordPressを使いたい
・情シス業務はいろんな人が兼務で賄っているベンチャーなのでサーバインフラのおもりはやりたくない
・WP使うとつきまとう脆弱性問題とかは気にしたくない
・今後Webマーケは強化していきたいから、LPになるコーポレートサイトはアクセス増える可能性あるけど、サーバのキャパシティプランニングなんてしたくない（しゃちょーがNHKや情熱大陸に出たい）
・Shifterの料金はほぼほぼそこらのレンサバ借りるのと同じ（Annual Tier1契約で1ヶ月あたり$12）だし、↑の要件は全部満たせる

ということで、無事Shifterを利用することに相成りました。

移行における反省点

社内調整がついたのでひとまず、Shifterにサインアップしてサイトを作成、Tier1にアップグレードして、Teamを作って、マーケ担当と制作会社がサイトにアクセスできるようにしました。
Shifter使ってみたかったけど、結局やることはこれくらいで、あとは公開する時にDNSの切り替えだけか〜、つまんないな〜、と当時は思っていたのですが、そんな訳ありませんでした。

その後、直面した課題

・そもそもGenerate Artifactがうまくいかない
・ルートドメインでサイト公開するためにはDNSの移行が必要
・コーポレートサイトが乗っているレンサバでコーポレートサイト公開以外のこともやってた
・www.eclect.co.jp → eclect.co.jpへのリダイレクトが必要だった

そもそもGenerate Artifactがうまくいかない
制作会社さんに納品してもらったテーマをShifterに乗せると、Generate Artifactがうまくいかず、各記事ページが404エラー表示のままHTML化される現象が発生しました。Shifterで使えないプラグインとかは入ってなかったんですが、function.php内で行っていたカスタム投稿タイプのパーマリンク設定がShifterと相性がよくなかったようです。制作会社さんが調査して、Custom Post Type Permalinksプラグインを使うように修正してくれたことで、無事Generateされるようになりました。
今更ながらShifterを使いたい理由やShifterの特性を早めに制作会社さんに説明して、納品前からGenerateのテストをやっていれば、双方費やす工数を減らせたな〜というのは大きな反省点です。
切り分け調査の途中で、WordPressが起動しなくなった時は冷や汗かきましたが、サポートの方に教えてもらったsafe modeで一命をとりとめましたw デフォルトテーマを適用した状態でWordPressを起動してくれるsafe modeの存在はみなさん覚えておきましょう！

ルートドメインでサイト公開するためにはDNSの移行が必要
ルートドメイン（今回のケースでいうとサブドメインなしのeclect.co.jp）でShifterで構築したサイトを公開するには特定のDNSサービスを利用する必要があります。Shifterがサイトごとに払い出すのは、IPアドレスではなく、ドメイン（xxxxx.cloudfront.net）です。そのため、ドメインとIPアドレスを紐付けるタイプのDNSレコードであるAレコードではなく、ドメインとドメインを紐付けるタイプのDNSレコードであるCNAMEレコードを利用する必要があります。
ところが、CNAMEレコードはルートドメインには設定できないのが世の理。CNAMEレコードがルートドメインに設定する必要がある他のレコードよりも優先されてしまうからです。普通DNSサービスではルートドメインにCNAMEレコードが設定できないように制御されていますが、自社でDNSサーバを構築している場合などは設定できてしまうことがあります。ルートドメインにCNAMEレコードを設定するととんでもない大惨事が起きますので、できたとしても絶対やらないようにしましょう。
とはいえ、やりようはあります。DNSサービスによっては、ルートドメインにドメインとドメインの紐付け設定ができるエイリアスレコードという機能が用意されているサービスがあり、それを利用することでルートドメインでShifterで構築したサイトを公開することができます。有名なのはAmazon Route53というAWSのDNSサービスです。ShifterもAWS上で稼働しているサービスなので、他に候補がなければRoute53を利用するのがおすすめです。
eclect.co.jpのドメイン管理はお名前.comのDNSサービスを使っていたのですが、Shifterを公開するためにRoute53に移行しました。Route53でShifter用のエイリアスレコードを設定する方法はこちら。
元サーバインフラ屋なので、分かっていたことではあったのですが、eclect.co.jpでサイト公開しなければいけないことに気付いたのが、サイト公開の割と直前で、バタバタとDNSの移行をしなければいけなかったのは、反省点の一つです。Shifter利用を検討する段階で、どのドメインでサイト公開したいか、どのDNSサービスを今使っているかは把握するようにすることをおすすめします。

コーポレートサイトが乗っているレンサバでコーポレートサイト公開以外のこともやってた
具体的には顧客への約款などのPDF資料配布をコーポレートサイトを公開しているサーバで行っていました。これも気付いたのが、サイト公開の直前で、気付いたからよかったようなものの、気づかずに切り替えていたら、いろんな部署から非難を浴びるところでした。Shifterに移行するWordPressサーバが他の用途で使われていないかも、Shifter利用を検討する段階で把握しておくべき必須事項ですね。
この時点で、Route53を使い始めていたので、AWSのサービスたち（ACM + CloudFront + S3）を使ってサーバレスのPDF資料配布環境を作りました。待ち時間含めてものの1時間ほどでできました。いや〜便利ですね〜。方法はいろんなサイトで紹介されているので割愛します。

www.eclect.co.jp → eclect.co.jpへのリダイレクトが必要だった
これに関してはShifterでサイト公開を始めたあとに対応しようと思ったせいで、回り道をすることになったのが反省点です。リダイレクト環境もPDF資料配布環境と同様にACM + CloudFront + S3で構築可能です。この方法もいろんなサイトで紹介されているので割愛します。
回り道をすることになったのは、Shifterに最初にeclect.co.jpをドメイン追加する際にwww.eclect.co.jpをAlternative Domainとして登録してしまっていたからです。Shifterにドメインを登録するとShifterが作ったCloudFrontのディストリビューションにCNAME設定が追加されます。CloudFrontのディストリビューションのCNAME設定には別のディストリビューションにCNAME設定されているドメインは追加できません。そのせいで、自分でリダイレクト用に作ったCloudFrontディストリビューションにwww.eclect.co.jpをCNAME設定できませんでした。
「新サイト公開されたぞ〜！わ〜い！」って社内がなってる中、こっそりDNSレコードを旧サイトに向けて、Shifterのドメイン設定をやり直すはめになりました。移行計画はしっかりしましょう。。。

最後に

なんだかんだありましたが11月から無事Shifterでのコーポレートサイト公開が開始できております。こちらです。
反省点はいくつかあるものの、実際にやってみないとわからないこと学べないこともたくさんあるんだなと改めて思いました。新しいサービスが実践投入できるチャンスを見つけたら、躊躇せずに飛び込んでみるのも大事ですね。このサイト移行のおかげで最近「情シス」と呼ばれるようになってますので、他にもいろんなチャレンジができればと思ってます！