GVA TECH株式会社 CTO 本田勝寛氏
GVA TECHは、オンラインで契約書のリスクを判定するサービス「AI-CON」を提供している。契約書をアップロードすると、条文ごとに5段階でリスクが表示され、どのように修正すればよいかも表示される。
2018年5月に正式リリースし、スタートアップやフリーランスを対象にサービスを提供。現在は弁護士が最終チェックを行っているが、将来的にはAIのみで判定し幅広い顧客に適正な法務サービスを提供することが目標だ。
昨年11月からクローズドで開始したこのサービスには、提供にあたっていくつかの課題があった。
まず、セキュリティの問題。契約書のサービスなので、顧客から高いセキュリティを求められる。一方で、スタートアップとしては開発スピードとイノベーションも不可欠になってくる。本田氏は、これらを少ない人数で両立させることに苦心したという。
実施した解決策として、まずセキュリティの問題に関してはアーキテクチャを「シンプルな構成にする」「導入・運用コストをかけない」の2点を挙げた。
「シンプルな構成」について本田氏は、「開発・本番のアカウントは完全に分割している。開発側はゆるくみんなに開放して、そこでイケているものがあれがどんどん本番に導入するというフローを取っている。また、サービス用途ごとにVPCを分割。サービスインした際も他のサービスに影響を受けることがないようにしている」と説明した。
また、「導入・運用コスト」については、各サービスの証跡をCloudTrailで取得。データの暗号化も行い、不正アクセスの検知はGuardDutyとSNSで実施しているという。さらに、Trusted Advisorsによるチェックと対応も行っており、これによって強固なセキュリティを実現。パフォーマンスと信頼性を担保しながら最小限の運用を実現している。
次に、少ない人数で開発スピードとイノベーションを推進する仕組みとして、運用する負荷を下げる対策を紹介。具体的には、下図の通りサードパーティの積極的な導入を行ったという。
「例えば、CircleCIの自動テストや、SideCIによるコードレビューの自動化、ログについても必要なもののみをSlackに通知しなるべく負荷をかけない運用にしています」（本田氏）
続けて、積極的な新規開発、技術・デザインの導入の取り組みについても紹介した。
「契約書のフィードバック画面という最も重要な部分について、昨年の11月から4回にわたってリニューアルを繰り返している。さらに、今月6月には新サービスのリリースも控えています」
加えてElasticsearch Serviseや、機械学習といった技術の導入も積極的に行っていると説明した。
株式会社スナックミー CTO 三好隼人氏
スナックミーはお菓子のサブスクリプションサービスを提供している。独自のアルゴリズムで顧客ひとり一人に異なるお菓子を届けており、まずはそのアルゴリズムが動いているアーキテクチャを紹介した。構成図は以下の通りだ。
こういったアーキテクチャになったのは、いくつかの課題を解決するためだった。三好氏いわく、この設計構築以前には次のような課題があったという。
「バッチサーバが立ち続けるコスト、不定期に生じる重い処理、また、それらの運用・結果確認をすべて手動で行っていました。加えて開発・本番環境の乖離、データが数万とあるので確認が簡単にできない、それらの実行から処理が終わるまで他のことができない…といった問題がありました」
これらの課題に一体どのように対応したのか。バッチサーバと重い処理に関しては、不要なリソースを削除して、時間的制約からAWS LamdaではなくフルマネージドなオートスケールのAWS Batchを採用。手動の運用については、SNSやCloudWatchを用いて通知を自動化した。
また、Dockerを社内で初めて導入。ECRでimageを共有することで開発・本番環境の乖離を克服した。結果が簡単に確認できない問題については、S3で期限付きURLを発行し簡単さとセキュリティを両立している。ボタン1つで完結するシステムを構築することで、すべての作業の自動化・効率アップを図ったという。
三好氏は「コスト面や、パフォーマンス、オペレーションや信頼性、セキュリティなど、多くの項目を満たす、完成度の高いシステムになりました」と話し、Well-Architectedの観点から優秀な設計を実現できたことを強調した。
さらにビジネス的成果としては、1週間の業務時間のうち、1人あたり10時間の作業時間削減、バッチサーバの費用は24分の1に削減された。その結果、技術的チャレンジをできる余裕が生まれ、新しい技術を積極的に採用できる環境が整ったという。
適切なソリューションを選択して課題を解決し、技術的挑戦の幅を広げたスナックミー。今後は、東京リージョン対応がアナウンスされたSageMakerやFargateにも挑戦していきたいと展望を語った。
ピクシブ株式会社 コミック事業部 Palcyチーム アーキテクト 石川勇太氏
続いて登壇した石川氏は、講談社とピクシブが共同開発したマンガアプリ「Palcy」のアーキテクチャについて発表。「好きなAWSはAPIGateway」と自己紹介をし、ピッチを始めた。
Palcyは、「作者と読者、双方のアクションを通じてマンガ文化を応援していくアプリ」。現在ユーザ数約4万人、120作品を抱えるこのアプリは、今年の夏に本リリースを予定している。Palcyのアーキテクチャは下図の通りだ。
今回、石川氏が紹介するのは特にオレンジの枠内、Webに関するアーキテクチャの部分だが、その前にAPIについて説明した。
「APIとは、API Gatewayを通じて通信しており、Cognitoで認証し、後ろのAPIで処理。AuroraはMySQLの5.7、プッシュ通知についてはPinpointを採用しました」
比較的新しいサービスを採用できたのは、製品の支援がよかったことと、社内で検証できる環境が十分にあったためだという。
オレンジの枠内は、LPページを形にしたり、アプリからシェアをした時のOGPの書き換えたり、シェアの集計などを行っている部分。
これをやるだけであれば、サーバを立ててアプリケーションをデプロイするだけでよいので、CF（クラウドフロント）とLamdaでも構成できる。しかし石川氏は「あえてAPI Gatewayを配置することにした」と話す。その理由は次の3つだ。
- API Gatewayはパスとバックエンドを切り離して設定できるため、将来的にバックエンドを切り替えやすい構成（プロモーションの時など）
- サーバを立てることなく低コストで実装
- API Gatewayを1つ経由すればよいため、シンプルさを維持
ただし、CDNの前にAPI Gatewayを配置したことで、気をつけなければいけないことも出てきたという。考慮した点について石川氏は以下のように語った。
「画像やCSSのアクセスは直接CFを参照させている。その方が、CDNの速さを生かせると思ったため。また、API Gatewayを経由することでCFではできないサブディレクトリのインデックスアクセスに対応できるようになりました」
最後に石川氏は、これらのポイントを踏まえた構成によって、高い信頼性を実現できたと説明した。
「API Gatewayを経由していてバックエンドを切り替えられるので、事業規模の成長によって適正なバックエンドに変更できる。また、例えばシェアをした時のURLのトラフィックだけ増えてきた場合など、部分的なリプレースも安全にできる。切り替え自体も、検証を行ってパスごとに切り替える方法なので、比較的安全である」と述べ、運用における信頼性が高いことを示した。
