KDDI Engineer Portal

powered byKAG

Blog

企業のTechポータルをApp Runnerで？？ KDDI Engineer Portalの使用技術とサービス構成の全容

2022/09/16

概要

社内/社外に公開されたKDDI Engineer Portal。 リリースまでに陥った事や、アーキテクチャの選定などについてまとめつつ、 SSR/SSG/ISRをAWSで動かす方法やApp Runnerの魅力、App RunnerにおけるBule/Greenデプロイの方法について紹介します。

内容

  • モダンなWebアプリケーション
  • SSR/SSG/ISRをAWSでホストする方法
  • 社内/社外のサイト構築 (KDDI Engineer Portal)
  • App Runner周りのお話
  • 技術以外で大変だったよ、こんなとこ

KDDI Engineer Portalとは・・？

  • KDDIエンジニアによる情報発信ポータルサイト
  • 業務としてKDDIエンジニアの文化や雰囲気を社内外の多くの人に発信できる場所。
  • 主な提供コンテンツ

Member, Blog, Article

また、社外ポータルのBlogページは2022年3月末で廃止された「KDDI Cloud Blog」の代替となる場としても提供しています。

Traditional Web ApplicationとモダンなWebアプリケーション

Traditional Web Application

  • 従来のwebアプリケーション

=> アプリケーションの処理は、サーバ側のみで実行

例えば、JavaならSpring、PythonのDjango、RubyならRailsとか

Traditional Web Application

モダンなWebアプリケーション

Reactive Web Application

  • アプリケーションの処理をサーバ側、クライアント側に分けて作り込む

  • Client Side Rendering (CSR)

=> CSRでできたアプリが、Sigle Page Application (SPA) – React, Vue, Angular とかとか

  • Server Side Rendering (SSR)

– Next, Nuxtとかとか

  • Static Site Generator (SSG)
  • Jamstackな仕組み, Gatsby, Hugo, Next, Nuxt とかとか
  • Incremental Static Regeneration (ISR)

– Next (9.4で追加された機能)

CSR (Client Side Rendering) / SPA (Sigle Page Application)

  • 最初に空のHTMLを取得し、ページ全体をJavaScriptで生成
  • クライアント側で取得したデータを基にページ遷移することなくページ全体を書き換える

CSR (Client Side Rendering) / SPA (Sigle Page Application)

SPAの課題

  • 初回アクセスでは巨大なJavaScriptを読み込んでから、ページ全体を処理する為、初回のロードが重くなる
  • 一番の問題は、SEO周り
    • 検索エンジンのクローラーが仮にJavaScriptを解釈しないものだと空のHTMLを解釈
    • 最近のGoogleのクローラーはJavaScriptの解釈と実行も可能
  • 動的なOGPの設定も大変
  • KDDI Engineer PortalについてはBlogも管理しているので、SEO対策だけではなく、OGP対策も必要になる。

SSR (Server Side Rendering)

  • リクエストに対して動的に生成されたHTMLを返却
  • JavaScript、仮想DOMなどをサーバーサイドでも利用
  • デメリットは、サーバーサイドの重さです。API通信などを利用すると、レスポンスに時間がかかる

SSR (Server Side Rendering)

SSG (Static Site Generator)

  • リクエストに対して事前に生成されたHTMLを返却
  • SSGではビルド時にHTMLを生成
  • 配信は非常に高速だが、デプロイ後はページ内容を動的に変更できない

SSG (Static Site Generator)

ISR (Incremental Static Regeneration)

  • リクエストに対して静的にビルドされたページを返す。
  • 有効期限を超えたら非同期で静的ページの再生成をSSRで行う。
  • キャッシュを活用しつつ、静的ページの更新を自動的に行え、一定時間後再度リクエストがあった場合、次回以降の内容をビルドするので内容が更新される。

ISR (Incremental Static Regeneration)

SSR/SSG/ISRをAWSでホストする方法

  • 必要なのはレンダリングするためのサーバ(Nodejsをセットアップしてあるサーバがあれば動く)

SSR/SSG/ISRをAWSでホストする方法

ISRをさせたい時に起こるキャッシュ問題

  • ISRでは、キャッシュを利用しHTMLを再生成

=> その為、インスタンスやコンテナがスケールするとキャッシュのタイミングがバラバラなので、LBからアクセスを受けるインスタンス、コンテナによってレスポンスされるHTMLの表示が変わってしまう。

KDDI Engineer Portalはどうしてる？？

KDDI Engineer Portalはどうしてる？？

実はAmplifyへのホスティングもできる

  • 静的サイトのデプロイパイプラインとホスティングが容易にできるサービス
  • SPAとかJamstackのホスティングには最適
  • 2021/5月にNext 9のSSRをサポート。7月に10/11もサポート
  • ISRもサポートしている。
  • Amplify => Serverless Next.js Componentがベースになっているっぽい

KDDI Engineer Portalの構成

フロントエンド

  • Next.js(version12-2022/5/19時点) + TypeScriptを使用
  • バックエンドとのやりとりをGraphQLで行っている => Apollo Client
  • CSSライブラリには、Tailwind CSSを使用 => ユーティリティファーストにしたかったのが強い(classの名前作るのが苦手なので、最高)

バックエンド

  • 短期間でリリースしたかったので、Headless CMSのContentfulを使用 => Contentfulは、GraphQLのEndpointも用意してくれる

社内/社外のアーキテクチャ(KDDI Engineer Portal) – 社内側

  • 社内側では、Serverless Next.js Componentという3rd partyのプロビジョニングツールを使用し、CloudFront + lambda@edge + S3という構成をとっています。
  • また、KDDI Engineer Portalでは、全てSSGでページ構成を行っているので、事前にビルドするためのジョブをCodeBuildを使用し作成しています。
  • CodeBuildは、EventBridgeにより1時間に1回実行するよう設定しています。

社内/社外のアーキテクチャ(KDDI Engineer Portal) – 社内側

社内/社外のアーキテクチャ(KDDI Engineer Portal) – 社内側のCD

社内/社外のアーキテクチャ(KDDI Engineer Portal) – 社内側のCD

社内/社外のアーキテクチャ(KDDI Engineer Portal) – 社外側

  • 社外では、App Runnerを使用しています。そのため、社内側で使用したCloudFront + lambda@edge + S3という構成が、App Runnerに置き換わったような形です。
  • また、こちらも全てSSGでページ構成を行っているので、事前にビルドするためのジョブをCodeBuildを使用し作成しています。
  • CodeBuildは、EventBridgeにより1時間に1回実行するよう設定しています。

社内/社外のアーキテクチャ(KDDI Engineer Portal) – 社外側

社内/社外のアーキテクチャ(KDDI Engineer Portal) – 社外側のCD

社内/社外のアーキテクチャ(KDDI Engineer Portal) – 社外側のCD

Contentfulのbackup/restore

  • Contentfulは、CLIが提供されておりCLI経由で作成したスキーマおよび入稿したデータのdumpファイルを作成/restoreすることができる

Contentfulのbackup/restore

なぜ社内と社外でアーキテクチャを変えたのか

  • 社内ポータルのアーキテクチャにおいてSSRを使用する際に、Lambda@edgeで処理させる

=> コールドスタートに時間がかかる。 定期的にウォームアップする方法もあるがめんどくさい。

  • ISRさせる予定もない。

What is App Runner???

  • そこで社外では、App Runnerを使用しコンテナで動かすことに変更した。
  • ちなみに、APP Runnerとは、「The easiest and fastest way to build, deploy, and run containerized web apps on AWS」 すなわち、AWS環境でコンテナのアプリをめっちゃ簡単にめっちゃ早く動かすことができるサービスです。

Why App Runner???

  • なぜApp Runnerなのかというとそれは本業をやりつつ、片手間で作ったappsを運用しなければならなかったこと。
  • そして、正直、Fargateだとしても運用するのしんどくない？？ と思ってしまったからです。

App Runner

  • Fargateだとコンテナ管理とかVPC周り、ALB、NLBとかAuto Scalingの設定とか、自動化するならCodebuildとかを組み合わせていたが、App Runnerは、これらをまとめて(隠蔽して)提供してくれる。

App Runner

App RunnerにおけるDeploy

  • App RunnerでのDeploy方法に自動でやってくれる機能がある。
  • 使い方としては、ECRにコンテナイメージをpushするか、GitHubにソースコードをpushすると、それを検知し、App Runnerがいい感じにコンテナをデプロイしてくれます。

App RunnerにおけるDeploy

App RunnerにおけるBlue/Green Deploy方法

  • 現在サービスとしては、Blue/Greenデプロイやカナリヤリリースの仕組みは提供されていない。
  • なので、無理矢理やるとすれば下記のような方法をとるとBlue/Green Deployが実現できる。
  • APP Runnerの自動デプロイの設定を片方(検証環境)のみ適用。もう片方は、手動デプロイ(本番環境)に設定
  • CloudFrontの代替ドメインを片方に適用し、付け替えるような感じ

　　* 現在本番環境になっているApp Runnerサービスのデプロイ設定を自動に変更 　　* 現在検証環境になっているApp Runnerサービスのデプロイ設定を手動に変更 　　* CloudFrontディストリビューションの代替ドメイン名を付け替える 　　* Route 53のAレコードとTXTレコードのルーティング先を入れ替える

App RunnerにおけるBlue/Green Deploy方法

引用元ブログ

最後に技術以外で大変だったよ、こんなとこを共有です。

  • 記事投稿の為のガイドライン作成
  • SLAが低いサービスでも社内のセキュリティシートの項目を埋め、かつ要件を満たすようにしなければいけない

=> よりmanagedなサービスを使うとセキュリティ設計書の項目を埋めるのがしんどくなる。

まとめ

  • 現在、たくさんのサービスに関わる全ての人がブログの執筆を行っています。
  • ぜひ、見にきてください！

引用/参考資料