重要なのは3つ――バックエンド開発者を目指すに当たって必要なスキルとは：メッセージベースのシステム、クラウドベースのサービスなど

バックエンド開発者になるために必要なスキルとは何か。新たにバックエンド開発者を目指す際に役立つ、3つの重要なスキルを紹介する。

» 2023年10月17日 08時00分公開

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　熟練のバックエンド開発者になるのに必要なスキルの習得に近道はない。明らかに知っておくべきと考えられるようなスキルもあれば、そうではないスキルもある。

　バックエンド開発とエンタープライズアーキテクチャに関するキャリアを目指すのであれば、この職への道のりに必要な一連のスキルはある程度予測できるだろう。一般的には、著名なプログラミング言語1つ以上に習熟すること、リレーショナルデータベースとNoSQLデータベースの両方の扱い方を理解すること、バックエンド開発の主要フレームワークを操作できること、コンテナオーケストレーションの経験があることなどが必要なスキルの中心になる。

　リレーショナルデータベースとRESTful APIの知識は不可欠だ。だが、バックエンド開発者が見落としてはいけない重要な開発概念は他にもある。

　バックエンド開発職を目指すのであれば、Node.jsランタイムやRESTful APIのビルドも重要だが、それと同程度に重要なスキルを見落としてはいけない。

　新たにバックエンド開発者を目指す際に役立つ重要なトピックが3つある。それは、メッセージベースのシステム、クラウドベースのサービス、そしてマイクロサービスとクラウドネイティブのデプロイメントのスケーラビリティと生産性を高める最新のデザインパターンだ。本稿では、この3つのトピックを確認する。

メッセージベースのシステム

　新人の開発者は、トピック、キュー、メッセージングを高度な分野だと考えることが多い。その結果、バックエンドにおけるこれらの重要な概念に精通するのを諦め、メッセージングをエンタープライズアーキテクチャに組み込むことに消極的になる。

　バックエンド開発者を目指すのであれば、メッセージベースのパブリッシュとサブスクライブのシステムをしっかりと理解する必要がある。このアーキテクチャには、次のようなメリットがある。

パフォーマンスとサービスの品質（QoS）の向上
信頼性の向上と回復力の強化
柔軟なスケーラビリティ
ディレード処理
コンポーネントの分離

　従来型の同期システムでは、クライアントがサーバに要求を行い、サーバからの応答を待機する。入出力（I／O）ベースのアーキテクチャでは、要求が行われるたびにサーバ側で新しいプロセスの作成がトリガーされる。そのため、同時要求数はサーバ側で作成できるプロセス数が上限になる。

　従来型アーキテクチャでは、サーバは要求を受け取った順に処理する。そのため、複雑なクエリを先に受け取ると、サーバ側の処理に時間がかかり、後から受け取ったシンプルなアクションが停滞して失敗する可能性がある。バックエンド開発者は、トピック、キュー、メッセージ処理をエンタープライズアーキテクチャに組み込むことで、同期型の相互作用を実現できる。

　メッセージベースのシステムでは、開発者は要求をトピックまたはキューに配置する。サブスクライブ側（SOAベースのコンポーネントや軽量のマイクロサービスなど）は、リソースが利用可能なタイミングでそのキューからメッセージを読み取り、受け取った要求を確実に処理する。これにより、サブスクライブ側はピーク時のワークロードを長期間に分散できるため、アーキテクチャの回復力が高まる。

　キューは受け取ったメッセージをカテゴリー別に分類することもできる。これにより、パブリッシュ／サブスクライブシステムは、複雑な要求を処理能力の高いサーバに処理させ、残りの要求を他のサーバに処理させることができる。

　モダンな環境では、バックエンド開発者はサブスクライブ側を軽量のマイクロサービスとして作成する。マイクロサービスは容易にコンテナ化でき、「Kubernetes」などのオーケストレーションツールを使って管理できる。そのため、メッセージベースのシステムは、最新のクラウドネイティブの環境に簡単に統合できる。

　以下の条件が当てはまる場合、バックエンド開発者はメッセージングとキューをエンタープライズシステムに組み込む必要がある。

クライアントは状態の変化を知るためにサーバにポーリングベースの要求を行う
要求の処理が遅れても、顧客のサービスの品質には影響しない
ストリーミングデータのリアルタイム計算は100％正確でなくてもよい
キューに配信されるメッセージを複数のサブシステムで処理できる
バックエンドサブシステムを動的にターゲット指定できるとサービスの品質が向上する可能性がある

　従来型のバックエンドアーキテクチャには、リレーショナルデータベースやNoSQLシステムを操作するアプリケーションサーバが関係する。バックエンド開発者は、この種のシステムの設計に精通し、習熟しているのが一般的だ。

　トピックやキューを組み込む場合、バックエンド開発者やシステムアーキテクトはエンタープライズシステムに新しいコンポーネントを組み込む必要があることが問題になる。初期のシステム設計には、ディレード処理、パブリッシュ／サブスクライブシステム、非同期通信などのシステムが含まれていないのが一般的だ。そのため、この種のシステムの使用を希望するバックエンド開発者は、新しいサーバ側テクノロジーを組み込まなければならない。

　現代のエンタープライズアーキテクチャにメッセージングシステムを組み込む場合、変化に対して消極的になることや、リスクを過度に恐れることが障壁になることが多い。

クラウドコンピューティング

　オンプレミスデータセンターでトレーニングを受けて経験を積んできたバックエンド開発者は、クラウドコンピューティングがもたらすメリットを見落とすことがある。現代企業で働く十分な資格を得るには、バックエンド開発者はラムダ式を作成してデプロイする方法と、クラウドでマネージドサービスをプロビジョニングしてデプロイする方法を把握しておかなければならない。

　サーバレスコンピューティングを利用すると、プログラマーはビジネスロジックをラムダ関数として作成し、コードをクラウドに直接デプロイできる。その際、基盤となるサーバのプロビジョニングや実行時のサービスの管理は必要ない。

　クラウドプロバイダーは信頼性の高いフォールトトレランスのインフラでラムダ式をホストする。そのインフラは、ラムダ式の呼び出しを処理するためにスケールアップまたはスケールダウンできる。インフラを管理する必要のないラムダ式とそれをサポートするサーバレスコンピューティングアーキテクチャにより、デプロイメントスタックが大幅に簡素化され、クラウドへのコードの継続的デリバリーが容易になる。

　サーバレスコンピューティングは実行時の管理オーバーヘッドが削減されるだけでなく、デプロイメントモデルが安価になる可能性がある。呼び出し単位に課金されるサーバレスコンピューティングモデルには、企業が支払うクラウドの費用削減する能力がある。企業のデプロイメントにおいて、こうした費用削減は機能以外の点で常に重要になる。

　バックエンド開発者は、クラウドで利用可能な多数のマネージドサービスを認識しておかなければならない。

　過去には、クラウドコンピューティングは、データストレージやリモートにホストされる仮想マシン（VM）用の信頼できる場所だと考えられていた。現在では、インストール、プロビジョニング、実行時管理の複雑さをクラウドプロバイダーが担うマネージドサービスを利用できる場所だと考えられている。

　例えば、以前ならコンテナベースのマイクロサービスをクラウドにデプロイする場合、クライアントは米Amazon Web Srevices（AWS）の「Amazon EC2」インスタンスなど、複数のVMをプロビジョニングし、マスターKubernetesノード、マスターノードのレプリカ、複数のワーカーノード、マスターノードとワーカーノード間のネットワークをサポートするソフトウェアをインストールする必要があった。

　つまり、実行時の管理、ソフトウェアのアップデート、ログ、アップグレード、監査はクライアントの責任だった。だが、AWSの「AWS Fargate」などのマネージドKubernetesサービスを使えば、クライアントはこうした複雑さから解放される。

　マネージドKubernetesサービスを使えば、環境を構成することなく、マイクロサービスを直接クラウドにデプロイできる。ロギング、監査、変更管理はクラウドプロバイダーが提供する。

　バックエンド開発者を目指すのであれば、サーバレスアプリケーションを構築してデプロイする能力を習得し、クラウドプロバイダーがクライアントに提供するフルマネージドサービスの種類を理解しなければならない。

クラウドネイティブのデザインパターン

　シングルトン（Singleton）、ファクトリー（Factory）、ブリッジ（Bridges）、フライウェイト（flyweight）は、開発者に広く知られるデザインパターンだ。こうしたデザインパターンは非常に一般的になっているとしても、残念だが、オーケストレーションが行われるコンテナにホストされるクラウドネイティブのソフトウェアの継続的デリバリーから作成された新しいデザインパターンはあまり認識されていない。

　全てのバックエンド開発者は、標準のGang of Four（GoF）デザインパターンとそのカテゴリー（生成、振る舞い、構造）を知っておかなければならない。また、APIゲートウェイ（API Gateway）、サーキットブレーカー（Circuit-Breaker）、ログアグリゲーター（Log Aggregator）など、現代のクラウドネイティブのデザインパターンにも精通しておく必要がある。

　APIゲートウェイは、クラウドネイティブのデプロイメントでは一般的になっており、複数のマイクロサービスにアクセスする必要のあるクライアントに単一のインタフェースを提供する。APIの作成者がクライアントによって使われる単一の統一インタフェースを提供すると、開発、統合、テストが容易になる。

　さらに、APIゲートウェイはマイクロサービスが使用するデータ交換形式を、非標準形式を使用するIoTなどのデバイスが利用可能な形式に変換することもできる。

　クラウドネイティブの要求／応答サイクルでは、バックエンドリソースとのラウンドトリップが完了するまでの間に複数のダウンストリーム呼び出しが行われる可能性がある。ただし、呼び出しチェーンの末端にあるマイクロサービスの1つで障害が発生すると、マイクロサービスの呼び出しパイプラインが全て失敗し、大量の処理能力が浪費されることになる。

　失敗につながることを避けられない大量のマイクロサービス呼び出しを停止するため、クラウドネイティブのデザインパターンでは、この呼び出しの流れにサーキットブレーカーを含めるのが一般的だ。サーキットブレーカーは、マイクロサービスが失敗した場合や呼び出しの完了までに異常に長い時間がかかっているケースを認識する。

　エラーによってサーキットブレーカーが作動すると、クライアントは即座にエラー応答を受け取り、サーキットブレーカーが全てのダウンストリーム呼び出しを停止する。その結果、失敗した呼び出しを解決している間もマイクロサービスは機能を継続でき、クライアントの時間を節約できる。バックエンドシステムは不必要なリソースを浪費することがなくなる。

　あらかじめ定められた時間が経過すると、サーキットブレーカーは要求を再びダウンストリームに送信する。これらの要求に正常に応答が返されると、サーキットブレーカーはリセットされ、クライアントは通常通りに処理される。

　管理者は、ステートレスのクラウドネイティブアプリケーションを、分散クラスタに参加する任意のコンピュータノードにデプロイできる。ただし、コンテナベースのアプリケーションは、デフォルトでは共有フォルダや中央のリポジトリではなく、ノードのローカルHDDに全てのイベントをログ記録する。

　そのため、クラウドネイティブのデプロイメントでは全て、各ワーカーノードから中央のデータストアにログファイルをプッシュするメカニズムが必要になる。このログは、その後ログアグリゲーター内で管理される。

　このログアグリゲーターは、監査やトラブルシューティングの目的でログを格納するだけではなく、クラスタ内の複数のノードにアクセスするユーザーセッションや分散トランザクションを追跡できる形式にログを標準化する。

　クラウドネイティブの開発者は、マイクロサービスに関する重要なデザインパターンの知識に加えて、Twelve-Factor Appの原理にも精通しなければならない。この原理は、次のような幾つかの構成方法に関するガイダンスを提供する。