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

AWS事業本部インテグレーション部のいわほりです。

本記事はAWS Summit Tokyo 2019のセッションレポートです。

概要

• セッションタイトル：AWSを最大限活用した不動産業向けB2Bサービスのクラウドシフト事例
• スピーカー：株式会社いい生活 Webソリューション開発グループ CTO 松崎 明様
• 概要：以下のとおり

創業から20年近く一貫して不動産業向けの業務クラウドサービスを開発・提供してきたいい生活。 これまでオンプレミスで構築運用し続けてきた同社がいかにしてインフラをクラウドシフトしたのかを実例を交えてお話しします。

10年以上の長きにわたり運用・改善を重ねてきたクラウドサービスにおいて、蓄積された運用ノウハウを含めた無形資産をどうシフトしたのか、アプリケーションにどの程度の変更が必要だったのか、シフトによって現場にどのような変革がもたらされたのか、などお話しできる範囲で赤裸々に語らせていただきます。

昨今のクラウド案件の重要テーマの一つである、オンプレからクラウドへの移行についてのセッションです。

アジェンダ

1. 株式会社いい生活について
2. AWSを利用したクラウドシフトの経緯
3. 各サービスのAWSへの移行
4. 変化と今後の展望

以下、それぞれについてレポートします。

１．株式会社いい生活について

2000年の設立以来、不動産業界向けクラウドサービスの提供を主な事業としながら、不動産業界のDXを推進してきた

• 不動産業界向けの様々なソリューションをSaaSとして展開(統合不動産ソリューション、不動産コミュニケーションフラットフォーム)
• 月額課金のサブスクリプションサービスを展開
• 設立当初からシステムはオンプレ環境に存在する

２．AWSを利用したクラウドシフトの経緯

• AWS移行のモチベーション
  • 直接的なきっかけは、データセンターの老朽化(25年モノ)
  • メンテナンスや設備交換は都度行われているものの、古さは否めない
• 移行先を決定する必要に迫られた際の選択肢
  • 新しいデータセンターに移行
  • クラウドシフト(AWS以外も含めて)
  • ハイブリッド
• サービス開発＆運用をとりまく課題
  • 開発プロセスのアジャイル化とプロダクト数の増加
  • 近年、並行プロジェクト数やリリース回数は急激に増加している
    • リリースの高頻度化
    • 並行開発の増加
      • CI/CDパイプラインによる継続的なテスト・デプロイ
      • 多数の環境が存在(開発・テスト・本番)
    • ダイナミックなインフラリソース要求の増加
      • (例)「明日、性能試験用の環境を提供して」
      • (例)「テスト用に本番環境データをマスキングして提供して」
      • (例)「このテストデータはずっと残しておいて」
• マイクロサービス化に伴うコンポーネント数の増加
  • スケールアウト型のアーキテクチャへの移行
    • オブザーバビリティ(可観測性)の向上が必要
    • オートスケール＆セルフヒーリングへの対応の必要性
    • インフラのコード化に伴う再現可能なインフラの要求
    • コンテナ技術の導入の期待
  • プロダクト数と(特に)構成サービス数が近年急激に増加している
• 不動産業向け×業務システム(BtoB)特有の事情
  • サービス利用のライフサイクルが長い
    • 不動産会社の営業活動～会計業務までサポート
    • (特に)賃貸管理業は不動産会社のビジネスモデル自体が月次請求型ビジネスモデル
    • 10年以上利用しているお客様も多数
    • 仮に利用者数が一定な場合であっても、データは増加し続ける
  • 機密性・可用性・完全性要件が高い
    • 機密性：個人情報や付随するお金に関する情報が極めて多い
    • 可用性：サービスダウンが即業務停止につながるケースが多い
    • 完全性：データエラーが一般消費者の損害となり得る構図
  • ストックした情報の再利用性が高い
    • 不動産を扱う会社や住む人は変わっても物件のライフサイクルは長い
    • データの蓄積がビジネス価値につながる
• クラウドシフトの決断の要因
  • テクノロジー
    • インフラのコード化の必要性
      • 再現性の高さが求められるが、オンプレ環境では難易度高
      • クラウドなら標準化された方法の確立が可能
    • 新技術へのトライアルの容易性
      • クライド環境であれば、新技術の検証環境の整備が容易(オンプレ環境では難易度高)
  • 組織と人材
    • プロダクトチームの責任範囲の拡大
      • さらなる並行開発を促進するためには、インフラチームがボトルネックにならないように、アプリケーションチームでインフラ部分を担当できるようになる必要がある
    • 技術的な情報源の豊富さ
  • コスト
    • ダイナミックなリソースアロケーション
      • 余剰リソースの事前確保はサブスクリプション型ビジネスにはフィットしづらい
    • データセンターの老朽化は絶好の好機
      • 移行の理由として社内プロセスを通しやすい。このタイミングで通さない場合、次にいつチャンスが来るかわからない
    • サービス原価の見える化の促進
      • オンプレ環境ではサービス毎のコストを見るのは難しい
    • サービスレベル
      • オンラインマイグレーションの必要性
        • ゼロダウンタイム移行が求められる

３．各サービスのAWSへの移行

• AWS移行の概略と歩み
  • サービス全体の構成
    • コアシステム：いい物件Oneコアプラットフォーム
    • 周辺システム：不動産会社向け、一般入居者向け、オーナー向け、顧客基幹システムとの連携
  • 基本方針
    • まずは周辺システムから移行し、その間はコアシステムはオンプレ環境に残す
    • 最後に、コアシステムをクラウド環境に移行させる
  • 歩み
    • 2018年３月～８月：検討開始
      • 各社クラウドサービスの検討
      • PoC検証
      • 最終的にAWSの採用を決定
    • 2018年９月：移行開始
      • 疎結合で移行しやすい周辺システムを選定し、順次移行を実施
      • 実施方法は、リフト＆シフト
  • AWS利用の基本方針
  • 以下の方針は、AWSを利用するうえで、非常に重要と考えている
    • AWS Organizationsによるアカウントの集中管理
      • IAMユーザとグループはマスターアカウントのみに存在し、作成を一括で管理
      • 各サブアカウントではロールのみを定義
    • セキュリティ強化のために、MFAを必須としている
    • 月次でアカウント毎の利用料金の監査を実施
      • サービス毎の原価に反映させる
        • アプリケーション担当者にコストを意識させる
        • 十把一絡げになっていると(コストが配賦されないため)コスト意識が低下してしまう
    • コード化された構成のみを許容
      • 再現性を重視するため
      • 「構成結果の状態」を「宣言的に記述可能」な方式以外での構築を認めない
      • 全構成ファイルはgitで管理し、全変更を追跡可能とする
      • 環境差分はパラメータファイルを介した変数で管理し、パラメータファイル自体も追跡管理対象とする
  • サービス概要と移行戦略
    • 不動産会社向けサービス
      • 不動産メディア各社等に物件情報を配信するサービス
      • 連携先は30以上で、１日に延べ400万件程度送信
      • C#で書かれた.NET Frameworkベースのアプリケーション
      • Windows Server＋Microsoft SQLServerで稼働
      • リスト＆シフト戦略で移行
      • EC2(Windows Server)＋RDS(Microsoft SQLServer)をベースとした環境を構築
      • EC2のインスタンス数は20台程度
    • エンドユーザ(一般入居者)向けサービス
      • こちらも移行戦略はリフト＆シフト
      • 当初計画では、Elastic Beanstalkを採用する計画だったが、要求される細かい制御を行うためにECS＋Fargateに切替えた

４．変化と今後の展望

• 組織と人材の変化
  • 開発チームの意識の変化
    • インフラに対する意識
      • (オンプレ時代)「インフラはインフラチームが用意するものでしょ？」とお任せ
      • (クラウド移行後)非機能要件含め、自ら考えるようになった
    • コストに対する意識
      • (オンプレ時代)担当サービスに賦課されないため、意識していなかった
      • (クラウド移行後)担当サービスに賦課されるため、コストを意識するようになった
  • インフラチームの意識の変化
    • アプリケーションに対する意識
      • (オンプレ時代)無意識
      • (クラウド移行後)「アプリケーションが動くためのインフラとは？」を考えるようになった
    • 自らの業務に対する意識
      • (オンプレ時代)存在する構成を管理することが業務
      • (クラウド移行後)単なる構成管理では自らの存在価値がないため、「すぐ使える環境を提供できるにようにするためには？」と考えるようになった
  • キャリアパスの考え方の変化
    • (オンプレ時代)アプリケーション担当、インフラ担当
    • (クラウド移行後)サービスリード、テクノロジーリード
  • 人材の変化
    • 多能工が増え、結果的にアジャイル開発を進めやすくなった
  • テクノロジーの変化
    • コンテナ技術の導入が促進された
    • CloudFormationの活用によりインフラのコード化が促進された
    • 同じ構成が複数の環境で復元できる運用ができるようになった
    • 自動化＆無人化が促進された
• これから重要になってくること
  • オンプレミス環境における既存の課題をクラウド環境において解決するためのデザイン
  • 「どのようなマネージドサービスを使うか？」よりも「どのサービスを適材適所でどのように活用するか？」
  • AWS Organizationsによるユーザ管理とコスト管理
• 今後の展望
  • クラウドジャーニーは始まったばかり。重要ポイントをどう実践するか？
  • オンプレミス環境で稼働中のコアシステム「いい物件Oneコアプラットフォーム」の移行
  • 人材と組織の在り方・あるべき姿も模索中

感想

事業会社様の業務、システム、人材に関する生の声を聴けた貴重な機会でした。サービス提供者の一人として今後の活動に生かしたいと思います。

貴重な機会を提供いただいた関係者の皆さまに感謝いたします。