【Ltech#10】CloudFormation による LIFULL HOME'Sサイト問い合わせ情報登録APIの構築と管理

1Copyright© LIFULL All Rights Reserved.
Ltech#10
CloudFormation による
LIFULL HOME'Sサイト
問い合わせ情報登録APIの構築と管理
2020年1⽉28⽇
LIFULL Co., Ltd.
テクノロジー本部情報システム部 CoEユニット開発推進グループ
⻘⽊直之

はじめに
・本資料は2020年1⽉28⽇に株式会社LIFULL が開催したイベント
【Ltech#10 不動産・住宅情報サイト「LIFULL HOME'S」の中の⼈が語るAWS活⽤前線】の資料です。
・本資料に掲載している画像については、⼀部を隠したり加⼯した画像を表⽰しております。ご容赦ください。
・本資料内では、いくつかのクラウドサービスを利⽤している事を⽰す為、各サービスのロゴ画像を利⽤させて頂いております。
ロゴ画像については、以下のように引⽤元のURLを記載させて頂いております。
⽇頃から各サービスを利⽤させて頂いており、⾮常に活⽤させて頂いております。誠にありがとうございます。
https://www.tableau.com/ja-jp
Google BigQuery
https://cloud.google.com/icons/?hl=ja
https://www.salesforce.com/jp/
https://www.postgresql.jp/npo/logo https://www.docker.com/company/ne
wsroom/media-resources
https://serverless.com/
https://aws.amazon.com/jp/architectur
e/icons/

⻘⽊直之 (あおきなおひさ)
・2015年4⽉中途⼊社。
・LIFULLにはデータベース & インフラエンジニアとして中途⼊社、主にインフラ系プロジェクトを担当。
・LIFULL HOMEʼSデータベースサーバ等のインフラ設計〜構築〜管理。
・LIFULL HOMEʼSのオンプレミスサーバ群のAmazon Web Services(AWS)へのインフラ移⾏。
・上記の完了後、未来のLIFULLを⽀える新しいデータベースの形を考えていた頃、Salesforceに出会う。
・Salesforce開発を⾏う「開発推進グループ」という部署でグループ⻑とエンジニアを担当しながら、
SalesforceとAWS等を組み合わせて、個⼈情報管理やCRM等のシステム開発と普及を推進。
・たまにアウトプットしてます。( https://qiita.com/na0AaooQ )

本⽇のテーマ
CloudFormatonを⽤いた
AWS環境構築の⾃動化や管理のお話です。

1. はじめに〜全体像のお話〜
2. 本資料の題材となるシステムアーキテクチャ紹介
3. AWS CloudFormation の簡単な紹介
4. AWS CloudFormation によるAPI環境構築と管理のお話
5. まとめ

はじめに
〜全体像のお話〜

プロジェクト
• LIFULLでは様々なサービスがあり、様々なシ
ステム、データベース、ドキュメント、⼈が保有し
ているナレッジ等のデータがある。
• ⽇々新しいサービスやデータが増えている。
• 様々な場所にデータが散在。
• これら散在するデータを集め、繋げ、活⽤する
事で、ユーザ様へより最適な体験やサービス
をお届けしたい。
サービス
プロジェクトサービス
プロジェクトサービス

オムニチャネルとは、デスクトップからモバイル、オンラインからオフライン、またその他のすべてのタッチポイントを横断したチャ
ネル全体で、⼀⼈⼀⼈のユーザ様に対して、⼀貫性のある最適化された体験をご提供するマーケティング戦略。
⼀箇所にデータを集めて、オムニチャネルを実現。
LIFULLのエンドユーザ様へ最⾼のユーザ体験をご提供したい。
オムニチャネルの実現

各マーケットやサービスに散らばる情報を集め、
繋げ、相互活⽤していくCRMを実現したい。
LIFULL HOMEʼ等
LIFULLの各サービス
⼈が繋げていた情報を
Salesforce
Salesforceにより繋ぎ、CRM実現を⽬指す
LIFULL内の社内システム
(基幹系システム等)
マーケティング

本資料の題材となるシステムアー
キテクチャ紹介

• まずは、本資料の題材であるシステムアーキテクチャを簡単にご紹介します。
• SalesforceというサービスにはSFA(営業⽀援)、CRM(顧客関係管理)をはじめ、顧客中
⼼のデータベースを実現する上で、豊富な機能を備えています。ただ、ビジネス要件によって
は、Salesforce単独では実現が難しい場合もあるかもしれません。
• そのような場合、SalesforceとAWS他技術を組み合わせることで、かなり要件が実現しや
すくなる事があります。
• ここからは、LIFULLにおけるSalesforceとAWSを組み合わせたシステム開発事例とシステ
ムアーキテクチャを簡単にご紹介します。
※本資料に掲載している画像については、⼀部マスクした画像を表⽰しております。ご容赦ください。

• 個⼈情報管理機能 (詳細後述)
• CRMの基盤となる個⼈情報データベース
• お問い合わせデータ登録API
• お問い合わせユーザの名寄せ機能
• 問い合わせ機能 (詳細後述)
• LIFULL HOMEʻSサイト等で使⽤しているお問い合わせフォーム機能
• お問い合わせエスカレーション機能
• レポーティング機能 (詳細後述)
• LIFULLの営業活動における商談レポート⽣成機能
• AWSとS3によるSalesforceサイト上へのレポート配信機能
• その他機能 (詳細後述)
• LINEソーシャルログイン機能
• LINEメッセージ配信機能

問い合わせの
個⼈情報管理機能

各サイトの
お問い合わせ
個⼈情報
(属性情報)
問い合わせがあった
サービス名等
各LIFULLサイト問い合わせ登録API
Salesforce
問い合わせ
フォーム個⼈情報
個⼈情報
(属性情報)
• Salesforce上に個⼈情報を格納するデータベースを構築。
• LIFULL HOMEʼSサイト等のユーザ様の問い合わせ情報をSalesforceに登録。
• 現在は⼀部サイトのデータのみ登録しているが、順次対象サービスを拡⼤。
各LIFULLサイト
個⼈情報
様々なLIFULL
データベース
各種データ
Tableauによる
商談レポート⽣成

• Salesforceは年3回のメジャーバージョンアップ時間帯、サービス利⽤不可となる。
• Salesforceシステムメンテナンス等の時間帯も含めて、24時間365⽇、お問い合わせデー
タを登録できるようにしたい。AWS上に問い合わせデータ登録APIを開発。
• API GatewayやLambda等を利⽤し、Salesforceへ問い合わせデータを登録している。
各LIFULLサイトが
稼働するAWS環境
Salesforceへのデータ登録
APIが稼働するAWS環境
Salesforceの
オブジェクト
取引先
(個⼈取引先)
お問い合わせ
個⼈情報
属性情報

• LIFULL HOMEʼSサイトの問い合わせフォームで、問い合わせを⾏うと、お問い合わせデータ
登録APIにより、Salesforceにお問い合わせデータと個⼈情報が登録される。

AWS CloudFormation
の簡単の紹介

• AWS CloudFormationとは「すべてのクラウドインフラストラクチャリソースのモデル化とプ
ロビジョニング」するAWSのサービスです。
• https://aws.amazon.com/jp/cloudformation/
• AWS CloudFormationを簡潔に表現すると、コードによるAWS環境構築と管理の⾃動
化サービスです。
• AWS環境の構成や設定情報をコード(yaml等)に記述し、記述したコードをAWS環境の
「CloudFormation」にデプロイすると、コード通りにAWS環境を構築できます。
• CloudFormationを利⽤すると、VPC, IAM, KMS, ACM, DynamoDB, Lambda,
API Gateway等のAWS構築や設定作業を⾃動化できます。

• AWS CloudFormationで「スタック」を作成し、 CloudFormationにコードをデプロイ
すると、AWS環境構築や管理を⾃動化できます。

• 例えば、CloudFormation⽤にVPC作成コードを記述し、 CloudFormationへデプロ
イすると、コード通りにVPCを構築できます。

AWS CloudFormation
によるAPI環境構築と管理のお
話

• 前述のSalesforceへの問い合わせ情報登録API環境については、CloudFormation +
Serverless Framework + ESLint + Jest等を組み合わせて環境構築⾃動化や構
成管理をしています。そろそろ1年以上稼働させていますが、安定稼働しております。
各LIFULLサイトが
稼働するAWS環境
Salesforceへのデータ登録
APIが稼働するAWS環境
Salesforceの
オブジェクト
取引先
(個⼈取引先)
お問い合わせ
個⼈情報
属性情報

CloudFormationDocker +
Serverless
Frameworkによる
ローカル開発環境
問い合わせ登録API
リポジトリ
• 簡潔にまとめると以下のような構成にしています。
• ローカル開発環境で開発し、ESLint + cfn-lint + Jestでテストをかけて、問題なければ、
AWS環境へ反映されるようにしています。
push
(ESLintとJestによる
テスト実⾏)
CloudFormation
スタックへデプロイ

• 前述のSalesforceへの問い合わせ情報登録API環境構築にあたり、CloudFormation
を利⽤した主な理由をご紹介します。
No 分類理由
1 開発者/運⽤者の⼿作業オ
ペレーションコスト削減
システム初期開発時点では、開発者/運⽤者チームは私(⻘⽊)を含めて2名
かつ兼務(今は3名になった)の少⼈数チーム。環境構築や設定の⼿作業をな
くし、オペレーション負荷をなくしたい。
2 開発者/運⽤者の⼈材育成システム初期開発時点では、AWS経験者が私以外いなかったので、なるべく
管理⼿法はAWS公式の⼿法に統⼀し、CloudFormationの学習を通して、
開発者/運⽤者チームのAWSスキル習得・⼈材育成の機会にしたい。
3 冪等性の担保設定情報をコード化することで、誰が環境構築を⾏っても、同じ結果を得られ
るようにしたい。もしコードにミスがあっても、コードを修正して改善し、エンジニ
アがチャレンジしやすい状態にしたい。
4 構成管理と属⼈化防⽌⻑期間使っていくシステムかつ個⼈情報を扱うシステムの為、
設定情報をコードで管理し、構成を管理したい。属⼈化を防ぎたい。

• 今回紹介した環境では、ごく⼀部の設定を除き(詳細は後述)、すべてのAWSリソースの環
境設定情報をCloudFormationテンプレート化して、コード管理しています。
CloudFormationでコード化している主な設定は以下の通りです。
No 分類 CloudFormationで管理している主なリソース
1 ネットワーク系 VPC
2 Route 53
3 ACM (SSL)
4 セキュリティ/権限系 IAM
5 アプリケーション系 Lambda
6 SQS
7 DynamoDB
8 CloudFront
9 WAF
10 CloudWatch

• CloudFormation, Lambda, API Gateway(swagger.json)等のAWS環境の設
定情報やコードはすべてGitHubで管理しています。

• AWS CloudFormationの利⽤にあたり、設計の検討経緯を簡単にご紹介します。
• 初期設計時、CloudFormationコードのファイル(テンプレート)は1ファイルにまとめようと
考えた時期がありました。1つのファイルにすべての設定を記載すると、ある意味シンプルと考
えた為です。
• ただ、検討を少し進めた段階で、CloudFormationテンプレートを1ファイルにすべてまとめ
ようとすると、⾏数が肥⼤化し、メンテナンス性が落ちると判断しました。
• また、1ファイルが⼤きすぎると、ファイル内の⼀部を更新するだけでもCloudFormationテ
ンプレートによるスタック更新、もし問題があった時のCloudFormationスタックのロール
バックにも時間がかかります。

• 最終的には、ある程度関連し合うAWSサービス単位/機能単位で、CloudFormatioテン
プレートを分けることにしました。
• CloudFormationテンプレートの粒度設計にあたり、クロススタック参照で複数の
CloudFormationテンプレート間で設定を相互参照させることも考えました。
• が、CloudFormationテンプレート間の依存関係が複雑になるので、テンプレート間で連
携が必要な設定値は、パラメータ化し、 CloudFormationテンプレート外部から指定させ
ることにしました。
• CloudFormationテンプレートは、階層構造で表現可能、コメント記述可能なyaml形式
で統⼀しました。
• CloudFormationスタックには「削除保護」を設定します。これにより、万が⼀のオペレー
ションミスによって、CloudFormationスタック削除とAWS環境削除、ひいてはサービス停
⽌を防⽌します。

• 最終的には、以下のようなAWSリソースの設定情報をGitHub上でコード管理、
CloudFormationによる環境構築⾃動化や構成管理を⾏っています。
• VPC
• VPC, Subnet, Route Tabke, Internet Gateway, NAT Gateway, EIP, VPC EndPoint)
• Route 53
• DNS Hosted Zone, DNS Record Sets
• SSL (ACM)
• SQS
• DynamoDB
• Lambda
• API Gateway
• IAM
• IAM User, IAM Role, IAM Policy
• KMS
• CloudWatch
• CloudWatch Event, CloudWatch Log Group, CloudWatch Rule
• AWS WAF
• AWS CloudFront 等

• あえて、CloudFormationテンプレート化せず、⼿動で設定しているものが⼀部あります。
• 今回ご紹介したAPIやシステムは、個⼈情報を取り扱うシステムです。
• 万が⼀、CloudFormationテンプレート誤削除や意図しない問題により、AWSリソースや
環境が⾃動削除されてしまった場合でも、異常の検知は⾏えるようにしたいと考えました。管
理者ユーザや⼀部の監視設定はCloudFormation管理対象外とし、⼿作業で設定してお
ります。
• IAM User
• 私(⻘⽊)やAWSシステム管理者の⼀部のIAMユーザ
• AWS 監査設定
• AWS CloudTrailログ記録設定 (監査ログ)
• AWS CloudTrailログ保存⽤S3バケット作成
• AWS SNS (CloudWatch等の監視アラームをメールやChatworkで通知する設定)
• CloudWatchでAWS利⽤料⾦を監視する請求アラーム設定
• AWS Lambdaの環境変数に設定するSalesforce APIキー情報 + APIキーをKMS暗号化して設定する作業

• CloudFormationでAWS環境を運⽤したみて感じたメリット、デメリットをまとめてみました。
(あくまで今回紹介した環境下での、私個⼈の所感です)
メリットデメリット
・⼿作業を⾃動化できる。
・⼿作業で設定しているうちに、誰が何の設定を⾏っ
たか忘れてしまい、カオスになる状態を防げる。
・誰が設定をデプロイしても、コード通り環境が設定
される。
・設定情報がコード化されているので、コードベース
で設定を確認・検索・調査できる。
・CloudFormation内で記述した設定に不備や⽭盾があ
る場合、CloudFormationスタックへのデプロイ反映が
中⽌(ロールバック)されるので、障害発⽣リスクを減
らせる。
・(あえて挙げるとしたら)少し設定変更を試した
い場合、コード変更とCloudFormationへのデプロ
イが必要となる。
・(あえて挙げるとしたら)AWS初⼼者(AWSマネ
ジメントコンソールを初めて触るぐらいの⽅)が
CloudFormationを触る場合、初期学習コストがか
かる。

まとめ

•CloudFormationにより、AWS環境構築や管理を⾃動化すると、
環境構築や設定作業の⼿作業をなくしたり、属⼈化防⽌、冪等性を
担保できるので、とても良いです︕
•CloudFormationのコード分割粒度、どの範囲までコード化するか
は、ビジネスやシステム要件、AWS開発者/運⽤者チームの⼈数や習
熟度を材料に検討すると良いと思います。
•例えば、1ヶ⽉しか使わず、他の⽤途で全く転⽤しないAWS環境なら
ば、CloudFormationによる環境構築や管理の⾃動化はあえて⾏
わない・・という判断もありかと思います。(CloudFormationの初
期学習コストをなくすため)

ご清聴ありがとうございました。

【Ltech#10】CloudFormation による LIFULL HOME'Sサイト問い合わせ情報登録APIの構築と管理

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de LIFULL Co., Ltd.

Mais de LIFULL Co., Ltd. (20)

Último

Último (10)

【Ltech#10】CloudFormation による LIFULL HOME'Sサイト問い合わせ情報登録APIの構築と管理