開発者向け
カスタムドキュメントポータルの開発：開始方法
By Juraj Bielik
以前は、カスタマーエデュケーションチームの新しいドキュメントポータルのビジョンについて読むことができました。必要なすべての資料を準備した後、彼らは数人の開発者のチームである私たちにアイデアを持ってアプローチしました。この一連のブログ投稿では、開発者の観点から新しいドキュメントポータルを構築した方法について説明します。
ポータルの最終リリースに至るまでの継続的なプロセスと、私たちが下さなければならなかったすべての主要な決定と、全体を通して発生したすべての障害を皆さんと共有します。バックルアップ、あなたは面白い乗り物にいます。
手始めに、開発プロセスが始まったときに私たちが知っていたことを要約しましょう。
- データのソースは2つあります。コードサンプル用のGitHubとその他すべて用のKenticoKontentです。
- KenticoKontentのコンテンツモデルがどのようになるかについて大まかなアイデアがありました。
- プロジェクトは、複雑さが増すにつれて3つの主要なフェーズに分割されます。
さらに、外部の開発者であるJavaScriptスペシャリストがポータルのウェブサイト部分を担当することを知り、ポータルのバックエンド部分のみを担当することになりました。リリース計画とすべての要件を設定したら、最初のリリースの前に何をしなければならないかを指定し始めることができます。まず、テクノロジースタックを決定し、それに基づいてプロジェクト全体のインフラストラクチャを準備する必要がありました。その後、実際に適切なソリューションの開発を開始することができました。
マイクロサービスへの道
すでにKenticoKontentをデータのソースとして使用していたので、作業はほぼ完了していると考えることができます。ただし、バックエンドを検索エンジン、GitHubリポジトリ、Redocなどと統合することを含むプロジェクト全体の要件を考慮すると、このタスクは非常に困難であることがわかりました。私たちは本当に最初からすべてを正しくしたかったので、ウェブサイトのバックエンドのアーキテクチャを理解することから始めました。
Kentico Kontentは、プロジェクトのコンテンツが変更されるたびに起動するWebhook通知を開発者に提供します。これは私たちにとって完璧に思えました。新しい記事の公開、またはすでに公開されている記事の変更に確実に対応したかったのです。したがって、私たちの目標は、バックエンドをリアクティブにすることでした。これにより、ドキュメント作成者がKenticoKontentで行ったすべての作業が処理されます。もちろん、メンテナンスコストを可能な限り削減しながら、堅牢なインフラストラクチャを設計したかったのです。
Microsoft Azureの経験が豊富なため、そこでバックエンドサービスをホストすることにしました。さらに、私たち全員がJS / .NETフルスタック開発者を目指しているため、使用するプログラミング言語の選択肢は事実上2つに減りました。どちらの言語がより多くなるかによって、JavaScriptまたはC＃のいずれかを使用することになります。私たちのユースケースに役立ちます。
徹底的な調査中に、私たちにぴったりのMicrosoftAzure関数に遭遇しました。すべての利点を見てください。
- これらはサーバーレスのイベント駆動型コード実行を提供し、私たちのニーズに完全に適合しました。KenticoKontentまたはGitHubのいずれかからのWebhookに対応する必要がありました。
- それらは消費プランで提供されます—関数が実行されるときに計算リソースに対してのみ支払います。
- 関数は、実行回数に基づいてオンデマンドでスケーリングします。必要に応じて手動でスケールアップする必要はありません。
- JavaScriptとC＃の両方で記述できます。すばらしいです。
Azure Functionsが提供するすべての機能を確認したとき、 マイクロサービス上にバックエンドを構築するという決定は簡単でした。自律的に拡張できること、価値をより速く提供できること、または障害点を分離できることは驚くべきことでした。また、プロジェクト全体をオープンソースとして持つことで、さらに多くのメリットが得られました。KenticoKontentからのデータを消費する重要なプロジェクトで、複雑なユースケースをお客様に示すことができました。他の目標の1つは、ポータルのメンテナンスコストを最小限に抑えることでした。このため、豊富なサブスクリプションプランを備えたMicrosoftAzureは良い選択のように思われました。
インフラストラクチャのセットアップ
ただし、一般的に、マイクロサービスはポジティブなものだけを提供するわけではありません。この新しいアプローチには、いくつかの欠点もあります。これらは基本的に、分散システムを扱う際の問題を表しています。次に例を示します。
- 単一のモノリスではなく、多くの異なる個別のサービスを使用するには、各サービスが個別のユニットとして機能するため、運用、展開、および監視の労力を増やす必要があります。
- 小さな単一責任サービスは一般に単純ですが、プロジェクト全体がより複雑になります。各サービスが他のサービスと通信する方法を適切に設計する必要があります。事前の慎重な計画が必要です。
- サービスがネットワークを介して通信すると、ネットワークの遅延やメッセージ処理などによりプロジェクト全体のパフォーマンスが低下するため、パフォーマンスの予測は難しくなります。
- アーキテクチャがより複雑なため、システム全体のテストと監視が困難になります。
これらの欠点を最小限に抑えるために、次のことを行うことにしました。
- 展開プロセス全体を自動化します。
- 静的コード分析を追加します。
- MicrosoftAzure内の各サービスを監視します。
- システム全体の基本的なシナリオをカバーする統合テストを実装します。
- アーキテクチャの図を含め、デプロイされたすべてのサービスを完全に文書化します。
展開プロセスを自動化するためのツールとしてTravisCIを選択しました。これは、GitHubでホストされているソフトウェアプロジェクトの構築とテストに使用される継続的インテグレーションサービスであるため、私たちのニーズを完全に満たしていました。必要なのは、いくつかのデプロイメントスクリプトとtravis.ymlファイルだけでした。開発ワークフローに関しては、以下で構成されるGitflowワークフローを使用することにしました。
- プロダクションコードを含むマスターブランチ
- 本番環境にプッシュする前のテストに使用されるコードを含む開発ブランチ
- 新しい機能の開発が行われる機能ブランチ（準備ができたら、それらはマージされて開発されます）
Travisデプロイメントスクリプトのおかげで、開発ブランチまたはマスターブランチへのプッシュが成功するたびに、サービスがAzureに自動的にデプロイされます。これにより、マスターと開発の2つの異なる環境が残ります。ただし、 Webサイトでの未公開コンテンツのプレビューもサポートしたかったため、最終的に4つの環境になりました。
- ライブマスター-すべてのサービスのマスターブランチ+ライブ（公開）KenticoKontentプロジェクトデータ-実際のドキュメントWebサイト
- プレビューマスター-Webサイトのマスターブランチ-未公開のコンテンツが入力されたドキュメントWebサイトのみ
- ライブ開発-すべてのサービスのブランチを開発+ライブ（公開）KenticoKontentプロジェクトデータ-テスト用環境
- プレビュー開発-Webサイトの開発ブランチ-未公開のコンテンツが入力されたテストWebサイトのみ
最後に、統合テストをサポートするために、ライブ開発環境に似た5番目の環境を追加しましたが、KenticoKontentの別のプロジェクトに接続されていました。
静的分析に関しては、JavaScriptで記述されたサービスにはCodebeatを使用し、C＃サービスにはSonarCloudを使用することにしました。これらすべてのツールによって提供される無料のプランで十分であり、これもまた、新しいドキュメントポータルのメンテナンスコストを最小限に抑えました。それでも、サービスごとにすべてを個別に機能させるには、GitHubでもサービスを分割する必要がありました。それぞれが独自のリポジトリになりました。 GitHubのKenticoCustomerEducation組織にあるすべてのリポジトリを確認できます。
私たちのサービスの寿命とパフォーマンスを監視することは非常に難しいことが判明しました。すべてをAzureにデプロイした後、 ApplicationInsightsを適切にセットアップする必要がありました。少なくともそれは私たちが最初に考えたものです。さらなるブログ投稿でこの問題をさらに深く掘り下げていきますが、最初に、監視するいくつかのアラートルールに満足しました。
- Webサイトの平均応答時間（ライブマスター環境とプレビューマスター環境の両方）
- すべてのバックエンドサービスの例外
さらに、Azure上のApplication Insightsを常にチェックする必要なしに、何かが故障したときにできるだけ早く通知を受け取りたいと考えていました。そのため、新しいアラートが発生するたびにMicrosoft Teamsチャネル（内部コミュニケーションツール）を介して通知するいくつかのロジックアプリをセットアップしました。このアプローチには素晴らしい利点がありました。プロジェクトの最初のフェーズのリリース後、ライブWebサイトに問題が発生した場合はいつでも、顧客教育部門にロジックアプリから簡単に通知でき、開発者は通知を保持していました。私たちだけの開発環境について。
統合テスト、サービスの文書化、および図の設計に関しては、それらは定期的に発生する継続的なプロセスとして終了しました（そのようなタスクに費やされる曜日を想像してください）。この余分な努力はすべて、プロジェクトの終了時に非常に役立ちました。プロジェクトに取り組んでいる新しい開発者と現在のメンテナの両方をより迅速に参加させることができました。後で説明するように、マイクロサービスに基づく比較的単純なプロジェクトでさえ、非常に複雑になる可能性があります。
結論
全体として、インフラストラクチャを準備するために時間を費やすことは、私たちにとって賢明なステップであることが証明されました。ほとんどの場合、デプロイメントプロセスについて考える必要はありませんでした。ブランチにプッシュするだけで、それが可能になりました。静的分析は事前レビューツールとして役立ちました。これもまた、開発プロセスをスピードアップしました。
実装にかなりの時間がかかるだけでなく、その後の継続的なメンテナンスも必要となる新しいプロジェクトを開始しようとしている場合は、上記の点を考慮することは確かに悪い考えではありません。開発チームが実行しなければならない反復タスクの量を減らすだけでなく、プロジェクトと長期的に関与するすべての人々を支援します。
次は何ですか？
プロジェクトの各フェーズのリリースに向けて、私たちが遭遇したいくつかの障害について見ていきます。また、コードサンプルのストレージとしてKentico KontentをGitHubリポジトリと統合する方法、セミカスタムAPIリファレンスを実装する方法、検索機能を処理する方法についても説明します。要約すると、下の図に示すバックエンドアーキテクチャがどのように完成したかを知りたい場合は、ご期待ください。 :)
