マネーツリーではこうして課題を克服した――3件のプロジェクト例
当社ではAWS Fargateを採用しましたが、このメリットについて説明します。
第一に、コンテナを利用することは良いアイデアです。うまく構築されたイメージを使うことによってコンフィギュレーションの度重なる変更やパフォーマンスの調整などの必要性がなくなり、時間の短縮ができ、安定したシステムを実現できます。また、コンフィギュレーションの管理によってシステム全体の状況を把握することも可能です。
システム開発および業務上のコンプライアンスの観点からみると、AWS Fargate上でコンテナを利用することによってハードウェアやオペレーティング・システムのセキュリティ・レビューを削減することができ、またDockerエージェントを停止せずに更新することができます。コンテナは当社のVirtual Private NetworkやカスタムSecurity Groupsを使って安全で信頼できるプロダクトを作動させることができ、（AWS Certificate Managerによる）HTTPS接続のみを受け入れ、Application Load Balancerを使用したオートスケーリングに対応し、Amazon CloudWatchを使用した書き込み専用のログの保持ができます。
オペレーション上のインテグレーションの観点からみると、コンテナを利用することによってAWS Identity and Access Managementを使った監査可能な権限管理が可能となり、またAWS CloudTrailとAWS Configを使ってインフラストラクチャーの更新状況をチェックすることも可能となります。デプロイは比較的簡単です。システム全体はAWS CloudFormationを使ってデプロイされますが、アプリケーション・コードについてはAWS CodePipeline及びAWS CodeBuildを使ってデプロイされます。さらに、Amazon EC2 Container Registryを使ったDockerイメージのトラッキング、またその他のコンソール、タグ付け、請求などの多くの標準的な機能を活用しています。
また、インシデント管理の観点からみると、コンテナを利用することによって、AMIを手動操作することを回避し、Auto Scaling Groupがスポット・インスタンス・タイプや、レガシー・システムに不適切な接続をしないようにし、さらに部分テストから生じる予期しないエラーなどを取り除くことができるようになります。その結果、当社のシステムがどのように稼働し、継続的に改善されているかを再評価する機会となっています。
では、実際にAWS Fargate上で開発された3件のプロジェクトを紹介します。
上図は、当社のお客さまのシンプルなプロキシの設計の例です。2～3カ所のカスタマイズを要するプロジェクト案件の開発の要請でした。こういったアプリケーションの構築業務は当社の主要業務ではないのですが、AWSのさまざまなコンポーネントを利用し、またカスタマイズしたDockerイメージを付け加えることでこのプロジェクトを数時間でデプロイすることができました。IAMポリシー、SecutityGroupアクセスの最小化、AWS CloudWatch連携等々を活用することによって強固なセキュリティを保証しています。さらに、そのAWSのリソースの全てはAWS CloudFormationでデプロイされているので、インフラストラクチャーを正確に管理することができます。
次の例は少し複雑なソリューションで、当社の主要プロダクトとして開発されたものです。
最終的な設計はより複雑なものですが、このケースでは、当社は第三者データベース・プロバイダー（MongoDB Atlas）に対してゲートウェイにSSL、及びPrivateLink接続を使って、極めて強固なネットワークコミュニケーションにフォーカスしています。この主要なアプリケーションでは顧客ごとの独立型となっています。つまり、データの漏洩を回避するために同じAWS CloudFormation Stackをそれぞれの顧客に対してデプロイしているということです。AWS Fargateにあらかじめ備わっているオートスケーリング機能のおかげでコストの管理が可能となりました。
また、次の二つのイメージ図はAmazon EC2からAWS Fargateへの発展を示したものです。
この時の目的は、アーキテクチャのメンテナンスを簡潔化することでした。この仕組みによって、エラーの出る確率が減り、バグを容易に修復でき、プロセスを理解するのに必要な認知負荷を減らすことができました。これにより、社員の時間と精神的な余裕が生まれ、商品の改善により注力できるようになりました。
将来に向けてAWSのさらなる活用
当社は現在3つの大きな課題を抱えています。これらをAWSの力を借りて解決しようとしているところです。
現在の組織はプロダクトチームごとの編成となっており、各チームが個々の能力を高めて、独立して仕事に従事しています。われわれは現在、AWS CloudTrailが利用できなくなることや、取り扱いに注意が必要なデータへのアクセスをするなどの有害で望ましくない改変が生じることを回避する方策を検討中です。そのために、クロスアカウントポリシー、アクティブモニタリング、MFAの導入のためAWS ControlTowerなどのサービス利用を検討しています。
また、現在当社ではAWS CloudFormationをそのまま使っていますが、必ずしも理想的ではありません。AWS Cloud Development Kitのようなソリューションの方が、類似のスタックを作ることが容易なので望ましいと考えています。また、当社ではIAMへのアクセス権については非常に注意を払っています。効果的にアクセス権を与えられるように新しいメカニズムを構築する必要があります。
最後に、当社では全体的な効率化を継続的に高めていきたいと考えています。Amazon AuroraやAmazon Elasticache for Redisは当社の新たな標準になっています。しかし、中には依然として変えていかなければならない古いコンポーネントも混在しています。ユーザーベースが着実に増加しつつある現状に鑑みると、当社は容量を上げながらもコストの削減に引き続き取り組んで行く必要があります。
AWSソリューションアーキテクトより一言
マネーツリーのAWSサービス活用のここがポイント！
FinTechスタートアップとして大変厳しいセキュリティ・コンプライアンス要件が求められるマネーツリーさんの、アーキテクチャの変遷が語られていてとても興味深いですね！ あえて私の独断でスキなポイントを3つ挙げるとすれば…
1. AWS Fargateでコンプライアンスを強化している
第1回で述べたように、AWSには責任共有モデルという基本的なセキュリティの考え方があります。AWS Fargateを使うことで、コンテナを動かすホスト以下のインフラストラクチャーはAWSが責任をもって運用管理してくれます。これは単に開発運用効率化だけでなく、コンプライアンスの観点でも有効な手段です。
2. AWS PrivateLinkで他社サービスとプライベート接続している
以前は専用線接続やVPNなどを個別に敷くなどが主な対応方法だったと思いますが、AWS PrivateLinkはより簡素に、素早くプライベート接続を構築できます。最近では、金融機関とFinTech企業が相互接続する際にAWS PrivateLinkが活用されたり、株式等のリアルタイムフィードサービスを提供する株式会社QUICKさんのフィードサービス（QUICK Feed）もAWS PrivateLinkに対応したりと、複数社のサービス間でよりセキュアなネットワークを構築しやすい状況が整ってきています。
3. マネージドサービスで金銭面以外のコストも削減できている
最後にぜひ挙げたいのが、マネージドサービスを活用することで「社員の時間と精神的な余裕が生まれ、商品の改善により注力できるように」なった点です。これこそがマネージドサービス活用の最たる恩恵ではないでしょうか。スピードが重要なスタートアップにおいて、マネージドサービスでUndifferentiated Heavy Lifting（他との差別化につながらない重労働）を排除することは大変有効なアプローチです。
といったポイントでしょうか！ 今後もさらなるコスト最適化やセキュリティの強化に取り組まれるとのことで、AWSスタートアップソリューションアーキテクトとしてぜひ支援させていただきたいと思います。
