ブログを月一で更新する目標で頑張っていた自分はどこに行ってしまったのか
クソザコエンジニアのjaramonです。 前回の更新から半年以上経ってしまいましたね。ごめんなさい。 (止むを得ない家の事情が発生していたので、アウトプットを止めていました。) また少しずつ、自分のペースで再開していこうかと思います。
AWS DevDay Tokyo 2019 で初めてのLTをしてきました！！！！
最近は色々とインフラ系イベントのCfP(Call for Proposalsの略。イベントでの登壇の募集)に応募したり、 LT(Lightning Talk)に応募したりと、登壇の機会を伺っておりましたが、ついにタイトルの内容でその第一歩を踏み出しました！！！ (これも半年前のイベントで、LT終わったら記事にしようと思ってたのですが、そのイベントの当日に止むを得ない家の事情が発生してしまいまして。。。)
と言うわけで、そのLTで発表した内容を纏めてみます。
読者対象
- AWSのRoute53、Cloudfront、S3を触った事がある方
- S3静的サイトホスティングでWEBサイトを運用したい方
- Wordpressが分からなくて運用を辞めたい方
今回はLPのサーバ(この言い方が正しいかは微妙)を移行する話です。前置き長めです。
第一章 LPの誕生と開発部
その昔、当社にちゃんとしたLPが必要となりました。 その時にどこからか声が聞こえました。
- AWS Lightsailという格安のサーバがあるよ！
- Wordpressがすぐ構築できるよ！
- Wordpressのデザインをやったことがある人が開発部内にいるよ！
- 社員数少なくても大丈夫だよ！
この声が聞こえたエンジニア達は、LPを開発部で作って管理しようと思い、無事にリリースしました。 LPも何事もなく、平穏な日々を過ごしていました。
第二章 マーケティング部 爆誕
それから数ヶ月、組織が大きくなるにつれてマーケティング部が誕生しました。 マーケティング部のKPIが決まると、やらないといけない事の中にLPの刷新がありました。 LPからの導線で資料を請求してもらう必要があり、マーケティング部にとってはそのLPが生命線となっていました。 その時、またどこからか声が聞こえました。
- LP改修依頼が来るけど開発部のリソース足りないよ！！
- マーケティング部に所属する方がWordpressを扱えるよ！！
- マーケティング部に任せてくれればWordpressのコードも外注して刷新するよ！！
この声が聞こえたエンジニア達は、インフラ以外の管理をまるっとマーケティング部に移譲しました。 そして外注によって進化したLPを無事にリリースできました。 かなりの反響をいただいたと聞きます。
。。。しかし、この後とんでもない事が起こることを、誰も気づきませんでした。
第三章 CXOと内製化
それからまた数ヶ月が経ち、LPにちょっとした修正は入りつつも、順調に稼働していました。 開発部にもデザイナーが増えた頃、CXO(Chief Experience Officer)が誕生しました。 そしてCXOが一言。
「LPもっさりしてるよね。直したいなぁ。何で構築してるんでしたっけ。」 (もっさり: トップページにコンテンツが多い && 読み込み速度が遅い)
クソザコエンジニアはこう言いました。
「Wordpressで構築しているのですが、インフラ以外はマーケティング部の管理となりまして。。。 コードも外注して作ってもらったので、どんな感じになっているか把握できていないです。」
＿人人人人人人人人人＿
＞ 把握できてないです ＜
￣Y^Y^Y^Y^Y^Y^￣
これが、とんでもない事の正体でした。 LPを外注してしまったが故、意図が分からないコードがたくさん生まれてしまいました。 Wordpressのデザインしたことがある当社のエンジニアもお手上げ状態。
と言うわけで、LP改善と共に内製化する目的で、脱Wordpress計画が始動しました。
技術選定
LP改善でやりたいことは以下の通りです。
- LPは生き物だからカジュアルに更新できるようにしたい
- 表示速度も早くしたい
- →静的サイトホスティングが良さそう
- でもコンテンツ量が膨大なので一度に移行できない
- せめてLPのトップだけでも先に刷新したい
- →Cloudfrontのパスパターンでいけそう
- デザイナーも増えたのでデザイナー主体で管理したい
- →Githubで管理
これを元に以下のツールを選びました。
- GatsbyJS（静的サイトジェネレータ）
- 開発部のほぼ全員がReactJSを使用している
- S3静的ウェブサイトホスティング（ホスティング）
- サブディレクトリのindex.htmlを自動で読んでくれる
- Github Actions（CI/CD）
- とりあえず使ってみたかった
Netlifyというドメインも管理できるCMSのSaaSも検討したのですが、 NetlifyのCDNサーバが日本にはなく表示速度が遅いこと、 ドメインはAWS Route53で管理していたためにNetlifyとうまく連携できなかったことから見送りました。
段階移行方法
CloudfrontのBehaviorのPath Pattern(URLのドメイン以下)によって、コンテンツの取得元をS3とするかWordpressとするか判断すれば可能です。
基本的にはWordpressを使用するURLはWordpressから取得、それ以外(Default)の場合はS3から取得すれば問題ありません。
その際に注意しないといけないことがあります。Wordpressでは /wp-hogehoge の様な独自のコンテンツをGETしていて、それはWordpressから取得するようにしないといけません。
これらを踏まえて、Wordpressの記事、イベント情報は残しつつ、トップページだけ変更したい場合のBehaviorの設定例が以下になります。
| Precedence | Path Pattern | Origin or Origin Group |
|---|---|---|
| 0 | /wp-* | Wordpress |
| 1 | /articles* | Wordpress |
| 2 | /events* | Wordpress |
| 3 | Default (*) | S3 |
後は記事やイベントのページを後からS3に保存して、このPath Paturnを削除するだけで段階以降ができます。
Wordpressで書く記事はどこで書くの。。。？
ContentfulというヘッドレスCMSのSaaSを使用して、マーケティング部や広報部の方が記事を書いています。 Contentfulにある記事データをAPIで取得して表示しています。
伝えたいことは。。。
会社の成長や組織の変遷に当たって、LPの管理部署は変わっていきます。 そのタイミングで技術選定をきちんと実施する必要があることの重要性を理解しました。 今ではLPのインフラはエンジニア、デザインはデザイナー、コンテンツはマーケターと、 それぞれ独立して動ける様になっていて、かなりハッピーです。
皆様もこの機会に一度見直してみてはいかがでしょうか！！！