“One of the huge successes of this re-platforming—and one of the reasons we’re doubling down on our relationship with New Relic company-wide—is that now we have a big monitor displaying everything that's happening at Morningstar.com. If there’s a blip in performance, we can tell within seconds. … Now we can tell immediately when the ground starts to shift.”
1984年に創設されたシカゴを拠点とするモーニングスターは、27歳の株式アナリスト、ジョー・マンスエト氏が立ち上げた企業です。彼は、一般の人々も財務専門家たちが顧客への助言に利用しているのと同種の情報を利用できるべきだと確信していました。その確信を基に、わずか8万ドルの創業資金を手に、この若き投資家は自分のアパートに店舗を構え、数人のスタッフを雇って一般向け投資調査を立ち上げました。
モーニングスターは、今では従業員5,000人を擁し、27か国で60万件を超える投資を手がけ、2,000億ドル以上の資産管理を行っています。同社は人々と投資情報・手段とを結び付ける商品/サービスを構築することで、この成長を遂げてきました。
その中心にあるのがMorningstar.comで、同社の商品/サービスへの顧客向けポータル機能を果たしています。Morningstar.comの技術チームは、2018年に至上命令を受けました。最高のスピードと安定性という2つの目標を目指し、7か月以内にサイトを再構築するというものでした。チームはこの機会をとらえて、長い間望んできたシンプルで透明なシステムを構築しました。
Morningstar.comでシニアエンジニアを務めるクレイ・グレゴリー氏は、このように説明しています。「私たちの最優先課題は、シンプルなシステム作りでした。当社は編集コンテンツを提供するウェブサイトです。投資家個々人がマーケットと自分の投資内容を理解するための手段を提供します。技術的には大きな課題はないため、基本に立ち返って物事を適正に行う機会となりました。例えば、システム運用を可視化して、変更による影響を理解した上で迅速に変更を加えられるようにすることなどです。
委任を受けた当時、Morningstar.comのアプリケーションは、主にエンタープライズコンテンツ管理システムと、Javaアプリケーションでホストされているバックエンドサービスを活用し、morningstar.comのユーザーにコンテンツを配信していました。
ところが、以前のアーキテクチャーでは何度も中断が生じ、大きな欠陥を抱えていました。例えば、トラフィック急増に対するスケーラビリティの欠如、パフォーマンス問題をすぐにピンポイントで突き止めてデバッグする能力の欠如、新商品・機能の立ち上げ速度が遅いことなどです。
最高度のスピードと安定性という譲れない要件に加えて、投資市場特有の突発的に急増する作業負荷パターンに対応するには、AWS Lambdaを利用することが自然な選択肢でした。
Morningstar.com のチームは、レガシーシステムの諸制約から解放され、AWS Lambda、API Gateway、S3、CloudFrontを既存のアプリケーションや内部サービスに接続したサーバーレスアーキテクチャーへのリプラットフォームを選択し、同社が必要とするスピード、効率、コストの削減を実現しました。
モーニングスターのシニアソフトウェアエンジニアのザック・アードマン氏は、このように述べています。「AWS Lambdaへの移行が実に容易かつ安価なのは驚きでした。マネージドサービスとこの膨大なデプロイメントが可能なエンタープライズアプリケーションを卒業して、これほど迅速な展開時間を実現できるとは感動ものでした。全面的なCIパイプラインが完成し、開発段階にあるものが20分以内に実用候補に変わることには、大きな意義がありました。
「このリプラットフォームの大きな成功のひとつは、New Relicとの関係を全社的に強化する理由のひとつでもありますが、Morningstar.comで起こっているすべてのことを大きなモニターに表示できるようになったことですパフォーマンスに少しでも何かあれば、瞬時に気づくことができます。……前提条件が変わり始めると、今ではすぐにそれが分かります。」
Morningstar社シニアソフトウェアエンジニア、ザック・アードマン氏
既存のアプリケーションを持つ多くの大企業と同様に、Morningstarもアーキテクチャーの面で白紙の状態からスタートしたわけではありません。既存のJavaと.NETサービスに加えて従来のビジネスAPIが混在していたため、7か月でまっさらなアプリケーションを構築し、レガシーシステム全体を整備するという選択肢はありませんでした。
グレゴリー氏は次のように述べます。「歴史ある企業では、すぐに再構築するほど優先順位が高くないものであっても、人々が使っているために残しておくことがあります。その結果、山のような言語とアプリケーションを抱え込むことになります。AWS Lambdaは、このばらばらの山を一つにしてくれました。」
グレゴリー氏とアードマン氏は、チームと協力して、再構築やAWS Lambda関数に置き換えられるコンポーネントを特定し、切り離すことに成功しました。彼らはは、モーニングスターの既存サービスと新サービスをつなぐ役割を担い、ユーザー体験、市場、ユーザーデータ、コンテンツ間のビジネスロジックを実現する機能の記述に注力しました。
新規アーキテクチャーの一部として、モーニングスターではCloudFrontを利用して、静的サイトアセットを格納したS3バケットからコンテンツを配信します。またCMSがサポートする企業マーケティングサイト、多様な社内サービス、API Gatewayを備えたLambda関数を使用して、動的コンテンツとユーザーイベントデータを配信しています。CloudFrontは、デフォルトで多層キャッシュを備え、領域エッジキャッシュを使用してレイテンシを向上させ、モーニングスター用オリジンサーバーの負荷を軽減しています。バックエンドではAPI Gatewayが重要なスケーリングコンポーネントの役割を果たし、同時APIコールの処理・経路指定を行い、スケーラブルにLambda関数をトリガーできます。
同社はこれまでにも、New Relic Syntheticsなどのさまざまな監視ツールを使って、システムが正常に稼働しているかどうかを定期的に確認していましたが、このプロセスはどちらかといえば後回しにされていました。またスタック自体が極めて不透明で、システムのエンドツーエンドの動作状況は誰にも分からないという状態でした。
アードマン氏は、「以前のソリューションでも監視はありましたが、それは二次的なものでした」と説明しています。実務の一部ではなく、社内アーキテクチャーでもありませんでした。Morningstar.comのリプラットフォームを開始した際、すべての計装を行えば、アプリケーションを上から下まで把握できることに気づきました。」
同社の提供物へのフロントドアとして、Morningstar.comではデータ/ツールやサービスを同社の他部門からだけでなく、第三者サービスからも取り込んでいます。つまり、Morningstar.comのユーザーが直面する問題は、もっと上流で発生している場合があるということです。
「組織的に非常に混在した環境であるため、New Relicは魅力的でした」とグレゴリー氏は述べています。「私たちのチームはクラウドを利用していますが、社内のすべての部署が利用しているわけではありませんし、制度的な知識も必要です。そのため当社の監視機能を、いかなる種類のプラットフォームであれ、同僚やパートナーが使用しているものに接続して、可視化することが極めて重要になります。」
New Relicの導入で、Morningstar.comチームはLambda関数の可視化、トレース、アラートが可能になり、動作が期待どおりでなければ迅速にデバッグでき、イノベーションを達成できます。しかし、アプリケーション、ランタイム、ビジネスAPIが混在する環境であるため、サーバーレスコンポーネントのみならず、エコシステム全体の可視化が必要でした。
「このリプラットフォームの大きな成功のひとつは、New Relicとの関係を全社的に強化する理由のひとつですが、Morningstar.comで起こっているすべてのことを大きなモニターに表示できるようになったことです」と アードマン氏は述べています。「パフォーマンスに異常があれば、数秒でその原因がわかるのです。 1年半前、問題の原因を突き止めるのに数週間どころか数日かかっていたことを考えると、大きな転換です。今では前提条件が変わり始めると、すぐに分かるようになりました。」
「うまくいかないことがあっても、私達は前に進みます。自分たちの処理を信頼できるようになっています。また、自分たちの監視を信頼できるようにもなっています。後ろに戻るのではなく、問題を解決することでサービスを復旧させます。New Relicのおかげで、問題に遭遇すると私たちは後退するのではなく前進することができます。これは気持ちの良いものです。」
Morningstar.com社シニアソフトウェアエンジニア、クレイ・グレゴリー氏
問題の究明や解決時間が激減しただけでなく、Morningstar.comでは、サイトのダウンタイムをほぼなくすことができました。Morningstar.comでは、以前は月に平均1回の大規模な障害が発生していましたが、リプラットフォーム以降の8ヶ月間は、障害発生がゼロとなっています。
「毎月、社内の各チームのリーダーが過去30日間に経験した主なインシデントを発表し検討する、全社的なインシデント検討会を開催しています。Morningstar.comのリプラットフォームを行い、New Relicを全社にデプロイして以来、報告すべき重大なインシデントが発生していないだけでなく、その事実そのものがニュースになり、CTOが実際に私たちの成功を呼びかけています」と、グレゴリー氏は述べています。
グレゴリー氏は、問題がすべてなくなったわけではない、と述べています。ただ、ユーザーへの影響やサイトのダウンが発生する前に、彼のチームがそれを発見し、解決することができるようになりました（または、適切なチームに再ルーティングして解決することもできます）。
このような監視に頼ることができるようになり、Morningstar.comのエンジニアリングチームは新しい機能をより早くリリースし、サイト上でのユーザー体験の向上に注力することができるようになりました。
グレゴリー氏は述べています。「私たちは小さなチームです。製品機能を提供する義務を怠ることはできません。技術的な問題の解決時間が少なくなれば、それだけ主任務にフォーカスでき、ユーザーに商品や有意義な結果を届けることができます。私たちはインフラ維持業務に従事しているのではないので、AWSとNew Relicの監視機能を手にすることで、本来の業務に注力できます。」
ユーザーに影響が出る前に問題を積極的に検出・修正できる自信と新たなCI/CDを得ることで、Morningstar.comのチームは、立ち上げのストレスを大幅に減らし、開発速度を上げました。
「リプラットフォームを行い、サイト全体に New Relicの監視をデプロイする前は、QAがコードの変更を見直すために1週間を費やし、恐る恐るリリースを出していました。」とグレゴリー氏は述べています。「それでも、誰もウェブサイトを閲覧していない午後9時から11時の間にしか、レビューを行うことができませんでした。それが今では、午後5時にリリースして、10分後には退社できます。失敗はないという自信があり、どこからでも見ることができるからです。」
サイトのリプラットフォームから8ヶ月間、チームがデプロイメントを巻き戻すことは一度もありませんでした。グレゴリー氏は述べています。「うまくいかないことがあっても、私達は前に進みます。自分たちの処理を信頼できるようになっています。また、自分たちの監視を信頼できるようにもなっています。後ろに戻るのではなく、問題を解決することでサービスを復旧させます。New Relicのおかげで、問題に遭うと当社は後退するのではなく前進することができます。これは気持ちの良いものです。」
グレゴリー氏にとってもアードマン氏にとっても、プラットフォーム変更と計装化された監視の、最も嬉しいくまた驚きでもあった面の1つは、エンジニアチームとビジネスチーム間の組織横断的なコミュニケーションが増えたことです。
アプリケーション監視に含まれる顧客や用途に関わるメトリクスに関して、ビジネスチームは、アプリケーションの健康状態がいかにビジネスの健全性に関係しているかに関心を示すようになりました。アードマン氏は述べています。「New Relicの監視で、エンジニアだけでなく、全員が数値を見る機会が生まれました。ダッシュボードは、全員が見守り、益を受けるものの1つになっています。」
スタックを監視できる弊社プラットフォームの全機能アクセスと、月あたり100GBのインジェストを無料で提供します。クレジットカードは不要です。
“If something is going haywire, we’re going to roll forward. We're going to trust our process. We’re going to trust our monitoring. And we're going to restore service by fixing the problem, not by rolling back. Thanks to New Relic, we can move forward through a problem rather than backward, and that feels really good.”
