AWSを最大限活用した 不動産業向けB2Bサービス の クラウドシフト事例

松崎 明CTO / 常務取締役株式会社いい生活

T 2 - 0 6

アジェンダ

自己紹介 / いい生活 のご紹介

Amazon Web Serviceを利用したクラウドシフトの経緯

各サービスのクラウドシフトの具体的な内容とポイント

AWSへのクラウドシフトによる変化

まとめと今後の展望

自己紹介

松崎 明

株式会社いい生活 常務取締役 CTO

2000年東京大学工学部卒業。

同年当時まだ10名程度であったスタートアップ直後の「いい生活」に出会い、

そのビジネス内容に惹かれてエンジニアとしてジョイン。

現在に至るまで、一貫して不動産業界向けのクラウドサービスの開発に従事し、

インフラ構築、Webサービス開発、プロダクト設計、アーキテクチャ設計など幅広い業務を経験。

2006年にCTOとなってからも、エンジニア組織全体のマネジメント業務を行う傍ら、

DevOpsプロセスの自動化やオブザーバビリティの改善といったSRE系の活動、

新技術を使ったプロタイピングなどのPoC、OSSを活用した自社フレームワークの開発、

開発プロセスの改善やプロジェクトモニタリングなどのPMO系の活動、メンバーの技術面での相談役など、

多岐にわたる業務を行っている。 (要は何でも屋)

20年来の Vimmer で 普段使う PCは Linux。最近は Kubernetes を中心にCNCF関連に関心が向いている。

会社概要

商号 株式会社いい生活

主力事業 不動産業界向けクラウドサービスの提供

設立 2000年1月21日

上場市場 東証二部 [3796]

資本金 628,411,540円 (2019年3月末現在)

従業員数 155名 (2019年3月末現在)

拠点 東京本社 〒106-0047 東京都港区南麻布5-2-32 興和広尾ビル

大阪支店 〒530-0011 大阪府大阪市北区大深町4-20 グランフロント大阪 タワーA

福岡支店 〒810-0001 福岡県福岡市博多区博多駅前3-25-21 博多駅前ビジネスセンター

名古屋支店〒450-6419 愛知県名古屋市中村区名駅3-28-12 大名古屋ビルヂング

不動産業界のDXを推進統合不動産業務ソリューション 不動産コミュニケーション

プラットフォーム

不動産業界向けの様々なソリューションを

SaaS として展開

MAU

1,415 法人

3,827 店舗

10,622 人

月額課金型のサブスクリプション

サービス

詳細は弊社サービスサイトへhttps://www.es-service.net/

AWS移行のモチベーション

直接的なきっかけは

データセンターの老朽化

• 社歴 ≒ 20年 → DC設備も25年級 (四半世紀！)

• メンテナンス・設備入れ替えなどもされてるが、古さは否めない

新DCにオンプレ移行？あるいは

クラウドシフト？

サービス開発・運用をとりまく課題

開発プロセスのアジャイル化とプロダクト数の増加高頻度化するリリース・増加する並行開発

CI/CD パイプラインによる継続的なテスト・デプロイ

多数の開発・テスト・本番環境

→ ダイナミックなインフラリソース要求の増加

→ テスト用データの維持・可搬性 (データモビリティ) の要求

0

20

40

60

80

100

120

2010年度 2014年度 2018年度

最大並行プロジェクト数 リリース回数

サービス開発・運用をとりまく課題

マイクロサービス化に伴うコンポーネント数の増加スケールアウト型のアーキテクチャへの移行

→ オブザーバビリティの向上が必要

→ オートスケール・セルフヒーリングへの対応の必要性

→ インフラのコード化に伴う再現可能なインフラの要求

→ コンテナ技術の導入の期待

0

20

40

60

80

100

2010年度 2014年度 2018年度

プロダクト数 構成サービス数

不動産業向け x 業務システム 特有の事情

• サービス利用のライフサイクルが長い• 不動産会社の営業活動～会計業務までサポート

• 特に賃貸管理業は不動産会社のビジネスモデル自体が月次請求型ビジネスモデル

• 10年以上利用しているお客様も多数

• 顧客数が増えなくても、データが増加し続ける傾向にある

• 機密性・可用性・完全性要件が高い• 個人情報やそれに付随するお金の情報が極めて多い

• サービスダウン = 業務停止 に即つながる

• データエラー = 不動産会社の先にいる一般消費者の損害の可能性という構図

• ストックした情報の再利用性が高い• 不動産を扱う会社や住む人は変わっても、物件自体の変化サイクルは長い

• データの蓄積がビジネス価値につながる

クラウドシフトの決断の要因

テクノロジーインフラのコード化 の必要性

• オンプレでも不可能ではないが難易度高

• 標準化された方法を手に入れたい

新技術のトライアルの容易性• オンプレでの環境整備の難易度高

組織と人材プロダクトチームの責任範囲の拡大

• さらなる並列化のためには独立稼働が重要

• インフラチームがボトルネックにならないように

技術的な情報源の豊富さ

コストダイナミックなリソースアロケーション

• 余剰リソースの事前確保はサブスクリプション型ビジネスにはフィットしづらい

DC老朽化は絶好の契機• このタイミングで実施しないと次のチャンス

がいつ到来するかわからない

サービス原価の見える化の促進• オンプレでは難しいインフラコストの按分が

不要になる

サービスレベルオンラインマイグレーションの必要性• ゼロダウンタイムに近いマイグレーション要件

• 段階的移行の必要性

サービス全体の構成

サービス全体の構成

クラウドシフトのタイムライン

AWS利用の基本方針 (抜粋)

AWS Organizations による アカウントの集中管理各チームごとに Dev & Staging, Production の2アカウントを用意

IAM ユーザ と グループ は マスターアカウントのみに存在し管理者が作成・管理

各サブアカウントではロールのみを定義し、Assume RoleによるRBACで制御

MFAを強制し、CLIを含む対話的な全ての操作でMFAデバイスによる認証が必須

月次でアカウント毎の利用料金を監査し、サービス毎の原価に反映する

コード化された構成のみを許容AWS CloudFormation または Kubernetes Manifest などの「構成結果の状態」を「宣言的に記述可能」な方式以外での構築を認めない

全ての構成ファイルは 社内のソースコードレポジトリで git 管理し、全変更を追跡可能とする

環境による差は、パラメータファイルを介した変数で管理し、パラメータファイル自体もコード管理の対象とする

サービス概要と移行戦略

• ESいい物件Oneで管理されている不動産物件の広告情報を写真/画像とともに、不動産メディア各社等に配信するサービス

• 連携先は30以上、1日に延べ400万件程度を送信

• C# で書かれた .NET Framework ベースのアプリケーション

• Windows Server + Microsoft SQL Server 上で稼働

• リフト & シフト戦略で移行

• EC2 上の Windows Server + Amazon RDS for Microsoft SQL Server ベース

• 外部連携 I/F を Amazon S3 + AWS Lambda + Amazon API Gateway で構築

FTPServer

AWS移行後のアーキテクチャ

AWS Cloud

VPC

Lambda Auth

サービス概要と移行戦略

• ESいい物件One の SFA/CRM 機能と連携し、不動産会社が見せたい物件情報等を一般消費者に見せるサービス

• モバイル / PC の双方からブラウザでアクセス

• Java で書かれたアプリケーション

• 一般的な Java の Servlet Container上で稼働

• リフト & シフト戦略で移行

• 最初は AWS Elastic Beanstalk で移行

• その後 細かい制御が必要になり、AWS ECS + AWS Fargate に変更

AWS Elastic Beanstalk 採用時のアーキテクチャ

AWSCloud

VPC

Elastic Beanstalk

container

VPC

AWS Fargate 採用時のアーキテクチャ

AWSCloud

VPC

ECS Fargate

VPC

Service Discovery

組織と人材の変化

開発チームの意識と活動の変化Before:

• OSやミドルウェアなどのインフラはインフラチームが用意してくれるもの

• 非機能要件とそれを実現するための構成の関心が薄い

• ソフトウェアを設計し、アプリケーションコードを書くことのみが仕事、という意識

• 運用もソフトウェアのパフォーマンスにばかり目が行ってしまう

• システム全体のデザインは既存システムを踏襲しがちな傾向

After:

• OSやミドルウェアなどを管理する必要性から非機能要件や構成設計を自ら考えるように変化

• コストの見える化により、不要なバックアップや不要なインスタンスなどの整理が進捗

• システム全体を設計し、サービス品質という目線で、DevからOpsまで一貫した観点で考えるようになった

• 新たなミドルウェアやフレームワークの心理的障壁が下がった

組織と人材の変化

インフラチームの意識と活動の変化Before:

• ハードウェア、OS、ミドルウェアなどのインフラが自分たちの主戦場という意識

• インフラの上に載るアプリケーションへの関心が低い

• インフラの設定をコード管理する、という概念への心理的抵抗

• 「秘伝のタレ」をついつい作りがちで、インフラがブラックボックス化しやすい

After:

• プログラムのソースコードと同じレベルでインフラ構成を管理するようになりつつある

• ハードウェア、OS、ミドルウェアを準備できることの価値が相対的に下がった結果、それらをうまく使うことが価値の中心に変化した

• 結果として、その上で動くアプリケーションをより意識するように変化した

• アプリケーションチームが「すぐに使える (Out-of-the-box)」なテンプレートを作成する、という役割に少しずつシフトし始めた

組織と人材の変化

キャリアパスと役割の変化Before:

• 組織の境界線が、インフラとアプリケーションという形に近かった

• その結果、キャリアパスも必然的に、インフラ系 or アプリ系 という区分に

After:

• Service Lead と Tech Lead という役割が生まれた

• Service Lead: サービス価値を重視し、機能改善と早期のデリバリーを目標とする役割

• Tech Lead: 効率性と開発・運用プロセスの最適化を意識し、技術によって仕組や効率の改善を目指す役割

• 開発チーム内に 2つの違う役割の人材が共存し、よりアジャイル的な多能工チームに変化

• 技術的な知見をサンプルやテンプレートという形で共有知にすることが価値に

テクノロジーの変化

コンテナ技術の投入Before:

• アプリケーションコードと環境設定を明確に分離する必要性が薄い

• プロビジョニングされたインフラに、設定とコードをまとめてデプロイするという方式

• アプリケーションを気軽に起動できるという点以上の価値の理解が薄い

• プロダクション環境で統制されたコンテナ実行環境をつくることのコストの高さ

After:

• AWS CloudFormation の活用によりインフラのコード化とパラメータ抽出が進捗

• アプリケーションコード、インフラ構成、環境パラメータの3つに分離することの価値が向上

• ソフトウェアの依存関係をパッケージ化しやすいコンテナ技術の価値を現場が理解

• ECS や EKS といったマネージドなコンテナ実行環境を手軽に利用できることも大きい

テクノロジーの変化

自動化・無人化の促進Before:

• インフラを管理するチームとアプリケーションを開発運用するチームが分かれていることで、どうしても設計・運用プロセスがそのバウンダリで途切れてしまう

• 結果的に、人手の作業が介在し、「作業手順」が多くなる傾向にあった

After:

• アプリケーション・デプロイメントプロセスとインフラ・プロビジョニングプロセスが一体化

• 監視プロセスの自動化や可監視性(オブザーバビリティ)の重要性が向上

• セルフヒーリングやオートスケーリングを設計上意識するように変化

まとめ

オンプレミス環境からクラウド環境へのシフトでは既存の課題をどう解決するかのデザインが重要

どのマネージドサービスを使うか？ ではなく適材適所でマネージドサービスを活用するためにどうするか？ が鍵

当社の場合AWS Organizations と アカウント ポリシーの適用による ユーザ管理とコスト管理

AWS CloudFormation の活用によるインフラの透明性と再現性の担保

アプリケーションチームへの責任委譲によるチームアジリティの向上

コンテナ技術の投入による 実行プログラム と インフラ構成 と 環境設定の分離

など

今後の展望

当社のクラウド・ジャーニーはまだ始まったばかりコスト最適化、リリースサイクル、サービス品質、チームアジリティなどの数値評価はこれから

オンプレミスで稼働中のコアプラットフォームの移行がまだ残っているここまでの実績で得られた知見と経験をもとにより良い形でのマイグレーションを実現したい

人材と組織構成のあり方も模索中クラウドを乗りこなすための組織編制と役割についてもより良い形を見つけていきたい

松崎 明CTO / 常務取締役株式会社いい生活

@akipom