rights reserved. S U M M I T 自己紹介 松崎 明 株式会社いい生活 常務取締役 CTO 2000年東京大学工学部卒業。 同年当時まだ10名程度であったスタートアップ直後の「いい生活」に出会い、 そのビジネス内容に惹かれてエンジニアとしてジョイン。 現在に至るまで、一貫して不動産業界向けのクラウドサービスの開発に従事し、 インフラ構築、Webサービス開発、プロダクト設計、アーキテクチャ設計など幅広い業務を経験。 2006年にCTOとなってからも、エンジニア組織全体のマネジメント業務を行う傍ら、 DevOpsプロセスの自動化やオブザーバビリティの改善といったSRE系の活動、 新技術を使ったプロタイピングなどのPoC、OSSを活用した自社フレームワークの開発、 開発プロセスの改善やプロジェクトモニタリングなどのPMO系の活動、メンバーの技術面での相談役など、 多岐にわたる業務を行っている。 (要は何でも屋) 20年来の Vimmer で 普段使う PCは Linux。最近は Kubernetes を中心にCNCF関連に関心が向いている。
rights reserved. S U M M I T 不動産業界のDXを推進 統合不動産業務ソリューション 不動産コミュニケーション プラットフォーム 不動産業界向けの 様々なソリューションを SaaS として展開 MAU 1,415 法人 3,827 店舗 10,622 人 月額課金型の サブスクリプション サービス 詳細は弊社サービスサイトへ https://www.es-service.net/
rights reserved. S U M M I T AWS移行のモチベーション 直接的なきっかけは データセンターの老朽化 • 社歴 ≒ 20年 → DC設備も25年級 (四半世紀！) • メンテナンス・設備入れ替えなどもされてるが、古さは否めない 新DCにオンプレ移行？ あるいは クラウドシフト？
rights reserved. S U M M I T サービス開発・運用をとりまく課題 開発プロセスのアジャイル化とプロダクト数の増加 高頻度化するリリース・増加する並行開発 CI/CD パイプラインによる継続的なテスト・デプロイ 多数の開発・テスト・本番環境 → ダイナミックなインフラリソース要求の増加 → テスト用データの維持・可搬性 (データモビリティ) の要求 0 20 40 60 80 100 120 2010年度 2014年度 2018年度 最大並行プロジェクト数 リリース回数
rights reserved. S U M M I T サービス開発・運用をとりまく課題 マイクロサービス化に伴うコンポーネント数の増加 スケールアウト型のアーキテクチャへの移行 → オブザーバビリティの向上が必要 → オートスケール・セルフヒーリングへの対応の必要性 → インフラのコード化に伴う再現可能なインフラの要求 → コンテナ技術の導入の期待 0 20 40 60 80 100 2010年度 2014年度 2018年度 プロダクト数 構成サービス数
rights reserved. S U M M I T AWS利用の基本方針 (抜粋) AWS Organizations による アカウントの集中管理 各チームごとに Dev & Staging, Production の2アカウントを用意 IAM ユーザ と グループ は マスターアカウントのみに存在し管理者が作成・管理 各サブアカウントではロールのみを定義し、Assume RoleによるRBACで制御 MFAを強制し、CLIを含む対話的な全ての操作でMFAデバイスによる認証が必須 月次でアカウント毎の利用料金を監査し、サービス毎の原価に反映する コード化された構成のみを許容 AWS CloudFormation または Kubernetes Manifest などの「構成結果の状態」を「宣言的に記 述可能」な方式以外での構築を認めない 全ての構成ファイルは 社内のソースコードレポジトリで git 管理し、全変更を追跡可能とする 環境による差は、パラメータファイルを介した変数で管理し、パラメータファイル自体もコード 管理の対象とする
rights reserved. S U M M I T サービス概要と移行戦略 • 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 で構築
rights reserved. S U M M I T 組織と人材の変化 開発チームの意識と活動の変化 Before: • OSやミドルウェアなどのインフラはインフラチームが用意してくれるもの • 非機能要件とそれを実現するための構成の関心が薄い • ソフトウェアを設計し、アプリケーションコードを書くことのみが仕事、という意識 • 運用もソフトウェアのパフォーマンスにばかり目が行ってしまう • システム全体のデザインは既存システムを踏襲しがちな傾向 After: • OSやミドルウェアなどを管理する必要性から非機能要件や構成設計を自ら考えるように変化 • コストの見える化により、不要なバックアップや不要なインスタンスなどの整理が進捗 • システム全体を設計し、サービス品質という目線で、DevからOpsまで一貫した観点で考える ようになった • 新たなミドルウェアやフレームワークの心理的障壁が下がった
rights reserved. S U M M I T 組織と人材の変化 インフラチームの意識と活動の変化 Before: • ハードウェア、OS、ミドルウェアなどのインフラが自分たちの主戦場という意識 • インフラの上に載るアプリケーションへの関心が低い • インフラの設定をコード管理する、という概念への心理的抵抗 • 「秘伝のタレ」をついつい作りがちで、インフラがブラックボックス化しやすい After: • プログラムのソースコードと同じレベルでインフラ構成を管理するようになりつつある • ハードウェア、OS、ミドルウェアを準備できることの価値が相対的に下がった結果、 それらをうまく使うことが価値の中心に変化した • 結果として、その上で動くアプリケーションをより意識するように変化した • アプリケーションチームが「すぐに使える (Out-of-the-box)」なテンプレートを作成する、 という役割に少しずつシフトし始めた
rights reserved. S U M M I T 組織と人材の変化 キャリアパスと役割の変化 Before: • 組織の境界線が、インフラとアプリケーションという形に近かった • その結果、キャリアパスも必然的に、インフラ系 or アプリ系 という区分に After: • Service Lead と Tech Lead という役割が生まれた • Service Lead: サービス価値を重視し、機能改善と早期のデリバリーを目標とする役割 • Tech Lead: 効率性と開発・運用プロセスの最適化を意識し、技術によって仕組や効率の改 善を目指す役割 • 開発チーム内に 2つの違う役割の人材が共存し、よりアジャイル的な多能工チームに変化 • 技術的な知見をサンプルやテンプレートという形で共有知にすることが価値に
rights reserved. S U M M I T テクノロジーの変化 コンテナ技術の投入 Before: • アプリケーションコードと環境設定を明確に分離する必要性が薄い • プロビジョニングされたインフラに、設定とコードをまとめてデプロイするという方式 • アプリケーションを気軽に起動できるという点以上の価値の理解が薄い • プロダクション環境で統制されたコンテナ実行環境をつくることのコストの高さ After: • AWS CloudFormation の活用によりインフラのコード化とパラメータ抽出が進捗 • アプリケーションコード、インフラ構成、環境パラメータの3つに分離することの価値が向上 • ソフトウェアの依存関係をパッケージ化しやすいコンテナ技術の価値を現場が理解 • ECS や EKS といったマネージドなコンテナ実行環境を手軽に利用できることも大きい
rights reserved. S U M M I T テクノロジーの変化 自動化・無人化の促進 Before: • インフラを管理するチームとアプリケーションを開発運用するチームが分かれていることで、 どうしても設計・運用プロセスがそのバウンダリで途切れてしまう • 結果的に、人手の作業が介在し、「作業手順」が多くなる傾向にあった After: • アプリケーション・デプロイメントプロセスとインフラ・プロビジョニングプロセスが一体化 • 監視プロセスの自動化や可監視性(オブザーバビリティ)の重要性が向上 • セルフヒーリングやオートスケーリングを設計上意識するように変化
rights reserved. S U M M I T まとめ オンプレミス環境からクラウド環境へのシフトでは 既存の課題をどう解決するかのデザインが重要 どのマネージドサービスを使うか？ ではなく 適材適所でマネージドサービスを活用するためにどうするか？ が鍵 当社の場合 AWS Organizations と アカウント ポリシーの適用による ユーザ管理とコスト管理 AWS CloudFormation の活用によるインフラの透明性と再現性の担保 アプリケーションチームへの責任委譲によるチームアジリティの向上 コンテナ技術の投入による 実行プログラム と インフラ構成 と 環境設定の分離 など
rights reserved. S U M M I T 今後の展望 当社のクラウド・ジャーニーはまだ始まったばかり コスト最適化、リリースサイクル、サービス品質、チームアジリティなどの数値評価はこれから オンプレミスで稼働中のコアプラットフォームの移行がまだ残っている ここまでの実績で得られた知見と経験をもとにより良い形でのマイグレーションを実現したい 人材と組織構成のあり方も模索中 クラウドを乗りこなすための組織編制と役割についてもより良い形を見つけていきたい
opdavies
tenforward
kawaguti
oracle4engineer
subroh0508
gachimuchiengineer
cygames
abnoumaru
hr01
aki_moon
tkhresk
chrisshort
jakevdp
mclloyd
thekraken
dotmariusz
reverentgeek
jeffersonlam
shpigford
kneath
jmmastey
addyosmani
lara
