"Well-Architected"なアーキテクチャに必要なこととは？ 現役CTOたちが選出した、Startup Architecture of the year 2019【AWS Summit Tokyo】

今年も優れたアーキテクチャが集まった“Startup Architecture of the year”

　昨年初めて開催され、好評のまま終わった「Startup Architecture of the year ピッチコンテスト」。今年もファイナリストたちが各5分のピッチで自社のアーキテクトについて熱いプレゼンテーションを披露した。

　グランプリの「Startup Architecture of the year」は、昨年と少し趣向を変えて、会場のCTO6名（以下）がピッチを聴いたうえ、投票によって選出する。

• グリー　藤本真樹氏
• DMM.com　松本勇気氏
• メルカリ　名村卓氏
• ユーザベース　竹内秀行氏
• dely　大竹雅登氏
• フロムスクラッチ 井戸端洋彰氏（昨年のStartup Architecture of the year受賞）

　加えて昨年同様、アーキテクチャのプロであるAWSのソリューションアーキテクト4名が判定・選出する「AWS SA 賞」、AWS Summit会場内に展示された各アーキテクチャ図を見て来場者が投票し選出される「オーディエンス賞」の計3つの賞が用意された。

株式会社クラウドポート――若松慶信氏

　最初に登壇したクラウドポートのIT・業務管理部長/エンジニアの若松氏は、自社サービス「Funds」のアーキテクチャについて紹介した。Fundsは、資産運用をしたい個人と、お金を借りたい企業を結び、さまざまな貸付ファンドに投資できる、オンラインの金融サービス。

　アーキテクチャは下図のようになっている。

　これらのアーキテクチャの採用理由について、「まず、金融サービスとして必要なセキュリティを実現するため」と若松氏。金融庁から出されている「金融分野におけるサイバーセキュリティ強化に向けた取組方針」を重視しているという。また、少人数でも安全な運用を実現することを目指した。「社内にエンジニアは3人。3人の中でもトラブルを予想できるようにある程度枯れているものを中心に採用している」。

　続いて、Well-Architectedである理由として、若松氏は、7つのポイントを挙げた。

• 3層サブネットにNACLを適用し、ワークロードにSecurity Groupでルールを設定することで、トラフィックを必要十分に制限
• 本番、ステージング、QAã‚’VPCレベルで分離。共通のGateway VPCとPeeringで接続することで、本番環境とその他の環境の間の接続を防止し、オペレーションするにあたって接続可能なルートを最小限に限定
• AWS WAFとAmazon GuardDutyで、外部からの侵入や、VPC内部のコマンドコントロールの不正トラフィックを検出・分析
• IAM Roleのみでの認可管理を行うことで、サービスごとに必要十分な認可の付与や、&Credential管理を不要にして漏洩も防止
• ストレージレベルの暗号化と、KMSを用いたアプリケーションレベルの暗号化によって、データの保護のレベルに応じた複数のデータ保護手段適用
• オートスケーリングのスケジュールアクションを利用して、定期的にインスタンス数を増減させ、古いインスタンスをドレインする
• ログとメトリクスの記録は、Amazon CloudWatchã‚„Amazon S3 バケットを用いて、運用時のデータをあとから分析することが可能

　最後に、このアーキテクチャがどうビジネスに貢献しているか以下のように語った。

　「金融サービスなので、インシデント発生時のビジネスへの影響が非常に大きい。実際にインシデントが発生してしまうと億単位の損害が出てしまうので、そういったリスクを軽減し、発生した場合の調査・分析も可能にしている。アプリケーションレベルで言うところの二段階認証などはお客様の信頼につながるが、それをアーキテクチャレベルでも行うことで、顧客からのサービスに対する信頼を獲得できているのではないか」

株式会社justInCase――小笠原寛明氏

　株式会社justInCaseは、数行のコード追加で自社サービスに保険加入の機能を実装できるAPIを提供する保険会社。同社の小笠原寛明氏がジョインした時、このサービスのバックエンドは多くの問題を抱えていた。

　「保険契約に関するコードは3つのリポジトリに分散していて、それらが相互に参照し合っているため、デプロイしないとテストが動かせない。また、CIが整備されておらず、マスターのバージョンがリソースとして反映されているのか不明だった」

　こういったアーキテクチャの複雑化は、リリースの遅延にもつながってしまった。そこで小笠原氏は、「テストを書きたくなるアーキテクチャ」「デプロイがしたくなるアーキテクチャ」を目指し、アーキテクチャを“片付け”たという。どういうことか。

　まず通信を見直した。APIを経由していても環境によって名前が異なる、APIを経由せずコンテナを直接起動しているなどばらばらだった通信を、AWS Cloud Mapを使って整理。どの環境でもローカル同様にHTTPで起動し、参照時の名前も同一にした。

　また、「テストのたびにログイン/ログアウトをしなければならないと、全然テストを書きたくならない」と小笠原氏。この認証の問題は、Amazon API GatewayのCustom Authorizerを使って解決した。

　これによって、ローカルでも認証なしですぐできる環境を実現し、プルリクのマージまでの平均日数を従来の約5日から2日に短縮したという。

　また、デプロイも改善した。スタック間の関係性を大幅に見直し、AWS CloudFormationを丸ごとCIに載せた。これによって以前の何がデプロイされているのか不明な状況や、手作業のデプロイから解放された。それどころか、AWS CloudFormationの知識がなくてもテスト環境にリソースをデプロイできるため、新しいメンバーにとっても簡単で、デプロイの回数が1日平均10回にまで増えたという。

　「こうした片付けによって、チームに魔法がかかった」と小笠原氏。月の機能のリリース数は約12.5倍に増え、しかも新機能の7割は新しく加わったメンバーによる実装だという。アーキテクチャを片付けたおかげで、メンバーがテストを書きたくなり、デプロイがしたくなって、チームが「ときめいた」から実現できた状況だと小笠原氏は話した。