PostNLは、外注委託のITプロジェクトデリバリーから社内の製品デリバリー能力への移行から得た洞察とガイダンスを共有した。特にサーバーレスサービスに重点を置いたクラウドネイティブ技術を採用することで、同社は運用コストを削減しながら、生産性と市場対応力の大幅な向上を達成した。
PostNLはベネルクス地域で最大の物流企業であり、1799年創業の老舗だ。2012年に同社は100％クラウド戦略に採用し、その後、既製品に依存するのではなく、競争力のある物流ソフトウェアを構築するために、すべてのソフトウェアデリバリーを内製化することを決定した。
社内のソフトウェアデリバリー能力の構築を成功させるため、経営陣は、標準化とベストプラクティスの採用のための明確なガイドラインとガードレールを提供することを選択した。同時に同社は、エンジニアリング・チームが標準やガイドラインに影響を及ぼし、全体的なソフトウェア・デリバリーやクラウド戦略に影響を与えない多くの分野で選択の自由を持てるようにしたいと考えた。
PostNL および AWS Serverless Hero のプリンシパルエンジニアであるLuc van Donkersgoed氏は、同社が採用したエンタープライズフレームワーク内での技術とツールソリューションの選択モデルについて説明している。
[PostNLでは、技術、製品、サービスは「固定、柔軟、自由」モデルに従って分類されます。このモデルでは、「固定」カテゴリーには、組織全体で標準化されたトピックが含まれます。「柔軟」カテゴリーには、選択できる範囲の製品、サービス、標準が含まれます。チームには、これらの範囲内でどのソリューションを採用する自由があります。「自由」カテゴリーには、それ以外のすべてのトピックが含まれる。このカテゴリの中では、チームは自分たちの予算、アーキテクチャ、経験の範囲内で何を使うかを自由に決めることができます。
PostNLは戦略的に、AWSをパブリッククラウドプロバイダーとして選択し、クラウドネイティブ技術、特にサーバーレス専用のサービスのみを使用することを決定した。この決定を実施するために、同社はCloud Center of Excellence（CCoE）と名付けたAWSプラットフォームチームを設立し、エンジニアリングチームがAWSクラウドを活用するのを支援すると同時に、EC2のような望ましくないサービスの利用を防止することにした。
同社がサーバーレス化を決断したのは、アプリケーションのワークロードが変動性、特に日次や週次のパターン、さらには11月のブラックフライデーからバレンタインデーまでのホリデー期間に利用が集中することなどが理由だ。PostNLは、ビジネスのニーズに合わせてAWSのサーバーレススタックを採用した主な要因として、柔軟な価格設定、簡単なスケーリング、困難な問題を解決するためのクラウドプラットフォームの活用を挙げた。
/filters:no_upscale()/news/2024/10/postnl-serverless-enterprise/en/resources/1postnl-serverless-dynamodb-1729163100815.jpeg)
DynamoDBのオートスケール機能（出典：PostNL Engineering Blog）
アプリケーション・トラフィックの変動性を考慮し、PostNLはプライマリ・データベース・ソリューションとしてDynamoDBを活用し、プロビジョニングされたキャパシティが負荷に応じてスケールし、予期せぬトラフィックの急増に対応できる十分な余裕を持つように自動スケーリングを設定した。同社はまた、呼び出し回数が毎日変動し、数か月にわたって変化するAWS Lambdaの簡単ななスケーリングからも恩恵を受けている。エンジニアリングチームは、Typescript、C#、Rust、Pythonなど多くの言語スタックをLambdaで使用しているが、同社はJavaランタイムも許可している。
/filters:no_upscale()/news/2024/10/postnl-serverless-enterprise/en/resources/1postnl-serverless-lambda-large-1729163100815.jpeg)
ラムダ関数の呼び出し（出典：PostNL Engineering Blog）
PostNLのサーバーレスアーキテクチャは、Step Functions、API Gateway、SQSなど、AWSの他の多くのサーバーレスサービスを利用している。特定のケースでは、好みのサーバーレスを選択してもニーズに対応できない場合、チームはRDS、Neptune、Timestream、Fargateといった異なるサービスを使用することが許可された。
外部パートナーの利用から内部開発チームへの移行とサーバーレススタックの採用は、オーバーヘッドの削減、生産性の向上、運用コストの削減につながった。しかし、この移行にはエンジニアのスキルアップや若手開発者へのサポートの必要性など、課題が伴った。さらに、サーバーレスソリューションの構築には学習曲線があることから、同社は柔軟なアプローチを選択し、チームが常に純粋なサーバーレスオプションにこだわるのではなく、RDSやFargateのようなマネージドサービスを使用してソリューションを作成できるようにした。
Luc van Donkersgoed氏は、サーバーレスの採用を検討している組織に向けて洞察を共有することで、ブログ投稿を締めくくっている。著者は、サーバーレスがビジネスゴールに合致するのであればサーバーレスを検討し、指針から始めるようアドバイスしている。彼は、インフラのプロビジョニング、CI/CD、オブザーバビリティ、セキュリティに関する自動化の必要性を強調している。また、企業はクラウドの採用にあたって、単にリフト＆シットのアプローチに限定するのではなく、クラウドプラットフォームを受け入れ、クラウドアーキテクチャの総所有コストを徹底的に分析すべきである。最後に van Donkersgoed氏は、特にクラウドプロバイダーの機能速度が速いことを考慮し、常に学習することの重要性を強調する。