一休com on クラウド ~ 急成長を支える技術基盤とSRE ~

Transcript

1. 0 一休com on クラウド ~ 急成長を支える技術基盤とSRE ~
2. 1 自己紹介 • 徳武 聡 • システム本部 CTO室 所属 • 入社4年目 • 技術基盤の刷新やサービス運用の改善、SRE(サイトリライアビ リティエンジニアリング)などに携わる。
3. 2 本日の内容 一休の紹介 開発組織について 一休でのSite Reliability Engineering クラウド移行プロジェクト 具体的な移行事例 今後の取り組みとまとめ
4. 3 一休の紹介
5. 4 一休について • 1998年7月30日設立 • 2016年 ヤフーグループ入り • 従業員数 339名 (2018年7月現在) • エンジニアは約50名
6. 5 一休.com • 上質な宿泊施設予約 • 2000年誕生 • 会員数800万人超 • 高い成長率を維持
7. 6 一休.comレストラン • ファインダイニング予約 • 2006年誕生 • 高い成長率を維持
8. 7 新サービスのリリース & メディア紹介 • ホテルスパ予約サービス「一休スパ」 を11月にローンチ • https://spa.ikyu.com/ • メディア紹介 • 5年間ヒトヤスミしていたのに、なぜ「一休」は再成長したのか • http://www.itmedia.co.jp/business/articles/1811/21/news019.html • 一休社長 榊淳「イノベーション異論」 • https://trend.nikkeibp.co.jp/atcl/contents/18/00087/
9. 8 採用技術/ツール • サーバサイド • ASP.NET WebForms/MVC (VB.NET/C#) • Python, Flask, Docker • レストランサイトをPythonに移行中 ➢ https://user-first.ikyu.co.jp/entry/restaurant2 • SQLServer, Solr • フロントエンド • Vue.js, TypeScript, Webpack • インフラ • Amazon Web Service, Fastly • モニタリング • NewRelic, Datadog
10. 9 開発組織について
11. 10 エンジニアリング組織の体制 レストラン事業本部 宿泊事業本部 新規事業本部 システム本部 データサイエンス部 プロダクト開発部 10人 3人 プロダクト開発部 15人 4人 デジタルマーケテイング部 5人 10人 営業部 マーケティング部 営業部 マーケティング部
12. 11 事業部のエンジニアは目的型組織でミッションを追う 事業本部 システム本部 プロダクト開発部 UI/UX Partner Alliance etc… Application Platform SRE
13. 12 システム本部のエンジニアは側面から事業部を支援 事業部 システム本部 プロダクト開発部 UI/UX Partner Alliance etc… Application Platform SRE 新技術の導入 技術負債の返却 etc リソースプランニング リリースエンジニアリング Devops etc…
14. 13 一休でのSite Reliability Engineering システム本部 Application Platform SRE • SREという肩書のエンジニアはいない。 • システム本部のエンジニアがSREという活動を行っている。 • 必要であれば事業部のエンジニアも信頼性改善を行う。 × システム本部 Application Platform SRE 〇
15. 14 一休でのSite Reliability Engineering
16. 15 ※ SRE = Site Reliability Engineering • この発表では、 SRE = Site Reliability Engineering です。 • Site Reliability Engineerではありません。
17. 16 この発表を通して伝えたいこと ✓ SREはソフトウェアエンジニアリングを通じて障害を未然に防ぐ ことに注力することで最大の価値が提供できる。 ✓ そのためには、可能な限りのあらゆる成果物をソフトウェアエン ジニアリング=コーディングで生み出せるようにしておく。 ✓ そのために、クラウドや外部サービスを積極的に活用する。 ✓ 障害を未然に防ぐためのエンジニアリングに最大限注力する。
18. 17 そもそもSREとは? “要するに、私たちの仕事はシステム内でのアジリティと 安定性のバランスをとることなのです ” SRE本 第９章 「単純さ」 • アジリティ = 素早さ • システム内のアジリティ = システム変更の素早さ = 開発の素早さ • システムの素早い変更とシステムの安定さを両立させるためのエ ンジニアリングを行う。
19. 18 典型的なSREの活動 ( SRE本 第5章 「トイルの撲滅」より ) 1. ソフトウェアエンジニアリング ➢ コードの作成や修正を含む作業。 • 自動化スクリプトの作成、ツールやフレームワークの作成。 2. システムエンジニアリング ➢ プロダクションシステムの設定、設定の変更。 • サーバセットアップ。モニタリングのセットアップ。 • ロードバランサの設定。各種パラメータチューニングなど。 3. トイル ➢ サービスを稼働させるのに直結している作業で、繰り返されたり、手作業 だったりするもの 4. オーバヘッド ➢ 管理作業。採用や事務作業、ミーティング、評価など。
20. 19 1. ソフトウェアエンジニアリング ➢ コードの作成や修正を含む作業。 • 自動化スクリプトの作成、ツールやフレームワークの作成。 2. システムエンジニアリング ➢ プロダクションシステムの設定、設定の変更。 • サーバセットアップ。モニタリングのセットアップ。 • ロードバランサの設定。各種パラメータチューニングなど。 3. トイル ➢ サービスを稼働させるのに直結している作業で、繰り返されたり、手作業 だったりするもの 4. オーバヘッド ➢ 管理作業。採用や事務作業、ミーティング、評価など。 一休では2年前までは… 技術基盤エンジニアが担当 ビルド&リリーススクリプトの開発 開発環境の整備 インフラエンジニアが担当 物理サーバのセットアップ ハードウェアメンテナンス
21. 20 1. ソフトウェアエンジニアリング ➢ コードの作成や修正を含む作業。 • 自動化スクリプトの作成、ツールやフレームワークの作成。 2. システムエンジニアリング ➢ プロダクションシステムの設定、設定の変更。 • サーバセットアップ。モニタリングのセットアップ。 • ロードバランサの設定。各種パラメータチューニングなど。 3. トイル ➢ サービスを稼働させるのに直結している作業で、繰り返されたり、手作業 だったりするもの 4. オーバヘッド ➢ 管理作業。採用や事務作業、ミーティング、評価など。 作業内容の隔たりが大きかった 技術基盤エンジニアが担当 ビルド&リリーススクリプトの開発 開発環境の整備 インフラエンジニアが担当 物理サーバのセットアップ ハードウェアメンテナンス 大きな壁 作業内容の分断 属人化
22. 21 1. ソフトウェアエンジニアリング ➢ コードの作成や修正を含む作業。 • 自動化スクリプトの作成、ツールやフレームワークの作成。 2. システムエンジニアリング ➢ プロダクションシステムの設定、設定の変更。 • サーバセットアップ。モニタリングのセットアップ。 • ロードバランサの設定。各種パラメータチューニングなど。 3. トイル ➢ サービスを稼働させるのに直結している作業で、繰り返されたり、手作業 だったりするもの 4. オーバヘッド ➢ 管理作業。採用や事務作業、ミーティング、評価など。 今は… 両方ともソフト ウェアエンジニ アが担当 両方ともソフト ウェアエンジ ニアが担当 両方ともソースコードの作成、修正で完結できる。 壁の解消
23. 22 一休でのSite Reliability Engineering • ソースコードの作成、修正でSREが完結する。 • SREに巻き込めるエンジニアの数が増える。 • 専任者への作業集中が防げる。 • エンジニアリングのリソースをより合理的に配置できる。 システム本部 Application Platform SRE
24. 23 なぜ… なぜソースコードの作成、修正でSREが完結できるようになったの か。
25. 24 クラウド移行プロジェクト • 一休のサービスに関するすべてのインフラをクラウドに移行する プロジェクト • Amazon Web Serviceへ移行。2016年末にプロジェクトキッ クオフ。 • 約10人のエンジニアが携わる。 • 2018年4月に完了。 • 物理サーバを置いていたデータセンターを解約完了。 • Amazon Web Serviceでは賄えない部分もこの機会に積極 的に外部サービスを利用するように変更。
26. 25 クラウド移行のキモ 1. クラウドサービスのメリット、利便性を最大限享受できるかたち で移行を行う。 ➢ そのために必要なエンジニアリングには積極的に工数を投下する。 ➢ 必要であればプロダクトのコードも積極的に修正。 • 単に物理的な筐体が仮想マシンになっただけ、という移行には 絶対にしない。 2. この大きなプロジェクトの中で一緒に解消できる技術負債は積 極的に解消していく。
27. 26 Site Reliability Engineeringとしてのクラウド移行 総インシデント数 内インフラ起因のインシデント数 2016年下半期 12 5 2017年上半期 20 6 2017年下半期 12 4 2018年上半期 10 0 2018年下半期 16 0 • インシデント数の推移 • 2017年10月にアプリケーション移行完了 • 2018年2月にデータベース移行完了 • 2018年はインフラ起因のインシデントは0だった。
28. 27 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング
29. 28 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング
30. 29 アプリケーションサーバ 移行前の課題 ① • 10台以上のアプリケーションサーバを管理 • 設定変更が必要なら管理者が手動で1台づつ対応 • 例えば、月次のWindows Update • 毎月、担当者が全台を手動適用 • 物理サーバなので、何かあればデータセンターに行く必要あり • 変更に時間がかかる。 • 変更できる人が限られている。 • 本質的でない作業に必要以上に時間がとられる。 Problem
31. 30 アプリケーションサーバ 移行前の課題 ② • モノリシック(Monolithic)なウェブアプリケーション • モノリシック = 一枚岩 • ひとつのアプリケーションでサービスに関するあらゆる機能を 提供 • 顧客向け機能、施設向け機能、社内オペレータ向け機能が単 一アプリケーションで動作 • ソースコードの参照関係も複雑 • 新任の開発者が変更するソースコードを直感的に把握できない。 • 明らかに過剰スペックの物理サーバ • 関心事が適切に分離できていない。 • 適切なサイジングができていない。 Problem
32. 31 アプリケーションサーバ 移行前の課題
33. 32 アプリケーションサーバの課題に対する解決策 • アプリケーションサーバはAWS Elastic Beanstalkに移行 • TerraformでInfrastructure as Codeを実践 • アプリケーションは大規模リファクタリング • ユーザー単位で分割 • 物理サーバ依存のコードを撲滅 = Be Stateless! • AWSのサービスを積極利用 Solution
34. 33 AWS Elastic Beanstalkとは • 公式サイトによれば • “AWS Elastic Beanstalk により、開発者は AWS クラウドのアプリケー ションを迅速にデプロイし管理することがより簡単になります。 ” • “開発者は単にそのアプリケーションをアップロードするだけで、Elastic Beanstalk が自動的に容量のプロビジョニング、負荷分散、Auto- Scaling、およびアプリケーション状態モニタリングといったデプロイの詳 細を処理します。” • AWSのPlatform as a Service • アプリケーションに必要なミドルウェアをサービスとして提供する。
35. 34 AWS Elastic Beanstalkとは • EC2 + Elastic Load Balancing + AWS Auto Scaling の組み 合わせ • 一定以上の負荷でEC2インスタンスが自動で増える。 • EC2インスタンスが障害を起こしたら自動でLBから外れる。 • 自動で新しいEC2インスタンスがサービスイン • アプリケーションデプロイの仕組みも提供 • ローリングデプロイ、 Blue/Greenなどの仕組みを提供 ✓ インフラ管理の大部分をAWSにお任せできる。 ✓ 物理インフラに比べセットアップがはるかに簡単 Good
36. 35 Terraform+AMIでInfrastructure as Codeを実践 • AMI(Amazon Machine Image)はEC2インスタンスのテンプ レート。カスタマイズ可能 • TerraformはInfrastructure as Codeを実践するためのツール • Infrastructure as Codeとは • ソフトウェア開発の手法でインフラを管理する。 • インフラ構成を宣言的でコードで記述できる。 • コードなのでテストができる。 • コードなのでGitHubで管理できる。
37. 36 Windows Updateを適用するなら 新AMIをElastic Beanstalkに適用 新しいAMIを入手 新AMIでTerraformを更新 新カスタムAMIを作成
38. 37 すべての作業をコード変更で！ • インフラ変更に関するすべての作業をソースコードの修正 + CI/CDで実現 • CI/CDにcircleciを活用 • GitHubのPull Requestのマージをトリガにデプロイ開始 • Elastic Beanstalkが変更適用済のEC2を自動的に立ち上げて サービスイン • 変更適用前のEC2は自動的に破棄。サービスは無停止 Good ✓ コードの修正だけで変更を実現 ✓ 物理インフラに比べセットアップがはるかに簡単
39. 38 アプリケーション大規模リファクタリング① アプリ分割 • 移行プロジェクトで最も工数を費やした作業 • 分割しないとElastic Beanstalkが使えない。 • デプロイパッケージのサイズに上限があるから • この機会にソースコードの見通しを良くしたい。 • ついでにデッドコード、不要な機能を削除 • 顧客向け機能、施設向け機能、社内オペレータ向け機能を別の アプリケーションとして分離 Good ✓ コードがより簡単に理解できるようになった。 ✓ デプロイパッケージの作成も簡単になった。
40. 39 分割後の構成 Good ✓ 適切なサイジングが可能になった。
41. 40 アプリケーション大規模リファクタリング② Be Stateless! • アプリケーションサーバはいつ破棄されても大丈夫にする。 • Disposable(破棄可能) = Immutable(不変) • 一度構築したサーバの設定、ソフトウェアは変更しない。 • 変更するなら新しいサーバを作って古いのを破棄 • DisposableならStateless (状態を持たない) にする必要あり • 状態 = アプリ実行で生まれる、アプリ実行に必要な情報 • データベースサーバはStateful = 破棄できない。 • アプリケーションサーバはStatelessにできる。そうするべき。 • そのほうがアプリケーションがシンプルになる。 • 管理もしやすい。
42. 41 一休のアプリは状態を持っていた • サーバのアクセスログを日時で集計してアクセス解析していた。 • サーバを破棄したらログがなくなってしまう。 • アプリが生成したファイルを同期ツールを使って全アプリサー バに配布してダウンロードできるようにしていた。 • サーバを破棄したらファイルがなくなり404になってしまう。
43. 42 一休のアプリは状態を持っていた • サーバのアクセスログを日時で集計してアクセス解析していた。 • サーバを破棄したらログがなくなってしまう。 ✓ 機能を棚卸しして不要な集計を廃止 ✓ Google Analyticsのデータから集計 • アプリが生成したファイルを同期ツールを使って全アプリサー バに配布してダウンロードできるようにしていた。 • サーバを破棄したらファイルがなくなり404になってしまう。 ✓ ファイルをAWS S3にアップロード Good ✓ アプリケーションがシンプルになった。
44. 43 アプリケーション大規模リファクタリング③ AWS積極活用 • データセンターのファイルサーバはS3に移行 • GitHub管理する必要のない画像ファイルもS3へ • リポジトリのサイズを小さく • 画像へのリクエストをS3にオフロード • AWS Elasticache Redisでデータのキャッシュ • データベースの負荷軽減 • 応答の高速化 Good ✓ リポジトリが小さくなって開発スピードが向上した。 ✓ アプリケーションサーバ、データベースサーバの負荷軽減
45. 44 参考資料 • AWS S3を使った画像管理の改善について • https://speakerdeck.com/kensuketanaka/ikyu-storage-improvement • クラウド移行後に実施した画像最適化とサイトスピード改善について • https://speakerdeck.com/shotaakasaka/imageoptimize-sitespeed- up-ikyu-with-imgix • アプリケーションの分割とElastic Beanstalkへの移行について • https://user-first.ikyu.co.jp/entry/2017/12/08/110000
46. 45 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング
47. 46 ビルド/デプロイパイプライン 移行前の課題 • 頻繁にデプロイが失敗する。 • デプロイセット作成でエラー発生。 • デプロイフローの途中で止まる。 • リリース当番のエンジニアがマニュアルでトラブル対応 • リリースは事業部のエンジニアが当番制で担当している。 • 本来やるべき自分の仕事ができない。
48. 47 ビルドデプロイパイプライン なぜ不安定? • デプロイスクリプトが複雑で独自 • ロードバランサ、ファイル同期ソフトと連携して自前でカナリ アリリースを実現 • 変更分のみのデプロイを実現するため差分を抽出 • トラブル対応に多くの知識が必要で時間がかかる。 • ファイル同期ソフトが不安定 • 商用ソフトウェアだが動作不良になるケースがある。 • ビルドデプロイパイプラインが独自過ぎる。 Problem
49. 48 移行前のビルド/デプロイフロー ロードバランサー アプリケーションサーバ ファイル同期ツール ロードバランサから切り離す API経由で操作 • デプロイセットの作成 • ビルド • 変更差分の抽出 • ロードバランサの操作 • 対象サーバの切り離し • デプロイセットの配置 • ファイル同期ツールの一時停止 一時停止 一時停止
50. 49 ビルドデプロイパイプラインの課題に対する解決策 • 動作に必要なすべてのファイルをデプロイ • 差分デプロイをやめるためのエンジニアリングを実施 • Disposableにするには差分デプロイではダメ • ビルドは外部のCIサービスで実行 • Jenkinsをやめるためのエンジニアリングを実施 • デプロイパッケージの仕様は標準に合わせる • デプロイはElastic Beanstalkにお任せ Solution
51. 50 差分デプロイをやめよう • なぜ差分デプロイの必要がある？ • サイトのデザイン変更を素早く実現するため • フロントエンドの資材だけ素早くデプロイ • 一休.comはデザインが命 • 変更が高頻度な部分はデプロイ不要で変えられるようにしよう。 簡易なCMSを開発
52. 51 簡易CMSでバナー変更を楽ちんに! Elasticache Good • jsonをアップロードするだけでバナーを変更できる仕組みを開発 • アプリのデプロイと無関係にデザインを変えられる。 ✓ デザイナーの関心とアプリのデプロイが疎結合に ✓ デザイン変更の工数削減 ✓ 差分デプロイの廃止
53. 52 ビルドは外部のサービスで実行 • 外部のCI/CDサービスを利用 • ビルドの定義ファイルをアプリと同じリポジトリで管理できる。 • ビルド環境自体が状態を持たないようになっている。 • 問題が特定しやすい。 • ビルド環境の変更も定義ファイルを変えるだけでOK
54. 53 デプロイはElastic Beanstalkにお任せ • CI/CDはデプロイパッケージを作成してElastic Beanstalkにデプ ロイ指示をするだけ。 • デプロイ自体はElastic Beanstalkが安全に実行してくれる。 • ロードバランサからサーバの切り離し • 資材のデプロイとヘルスチェック • Elastic Beanstalkのデプロイパッケージ(zip)は512MB以下に する必要あり。 • 不要なコードを徹底的に削除 • 画像はなるべくS3に配置してデプロイパッケージから排除 • デプロイスクリプトも可能な限りシンプルに。
55. 54 変更後のデプロイフロー マージをトリガにビルド開始 APIでデプロイ指示 Windows環境で動作するアプリはAppveyor Linux環境で動作するアプリはcircleci Good ✓ ビルド/デプロイフローが安定 ✓ リリース回数が日次1回から日次3回へアップ
56. 55 参考資料 • 一休.comのビルド/デプロイの歴史について • https://speakerdeck.com/kensuketanaka/ikyu-deploy-flow • https://speakerdeck.com/minato128/ikyu-deploy
57. 56 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング
58. 57 ロードバランサー 移行前の課題 • アプライアンスを利用 • トラフィックの制御のルールがバージョン管理されていない。 可読性も悪い。 • 変更も手作業 • 特定のエンジニアしか変更できない。 • アプライアンスは保守作業が大変 • ソフトウェアのアップデート • 保守契約の更新 • トラフィック制御のルールがわかりにくい • メンテナンスが大変 Problem
59. 58 移行先を検討! • [案1]自前でnginxを立てて運用する。 • 可用性も自分たちで担保する必要がある。 • 設計が複雑になりそう。 • マネージドなサービスを活用したい。 • [案2] AWS Application Load Balancerに移行 • 既存のトラフィック制御のルールが完全に移植できない。 • オリジンサーバ側のリライト処理も修正が必要 • 工数がかかりそう。
60. 59 CDNサービス見直しでFastlyを検証してみると • Fastlyはリバースプロキシとして活用できそう。 • 既存のトラフィック制御のルールも移植できる。 • マネージドなサービス • 設定もプログラマブル
61. 60 Fastlyとは • CDN = コンテンツ配信ネットワーク • 効率的かつ高速にコンテンツを届ける仕組み • HTTPアクセラレータであるVarnishを利用している。 • Varnish = キャッシュ機構搭載のリバースプロキシ • VCL(Varnish Configuration Language)で柔軟にルーテ ィングできる。 • 大規模なサービスも使っているので信頼性も高そう。 • Fastlyに移行！ Solution
62. 61 VCLファイルの変更もInfrastructure As Code VCLファイルはGitHubで管理 マージをトリガにしてCIが起動 circleci上でTerraformが適用を実行 AWS Application Load Balancer AWS EC2
63. 62 キャッシュ機構も積極的に活用 • ゴールデンタイムのTVで宿泊施設が話題になる。 • 平時の2倍のアクセスが来てトラフィックがスパイク！ • Fastlyキャッシュがコンテンツを返すのでサービスには影響なし
64. 63 アプリケーション開発にも積極的活用 • 新機能の部分リリース • 特定のパラメータがあるときだけ新機能を有効にする。 • VCLファイルのデプロイが高速なので簡単に実験できる。 • リクエスト追跡IDを付与 • VCLでリクエストヘッダにユニークIDを付与 • アプリケーションログや各種メトリクスにユニークIDを出力 • リクエスト単位での調査がやりやすくなった。 Good ✓ 誰でもルーティングの定義が変更できる。 ✓ アプリケーション開発でも積極的活用 ✓ キャッシュ機構活用でサイトの信頼性アップ
65. 64 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング
66. 65 メールサーバー 移行前の課題 • Windows Serverのメールサーバ機能とアプライアンスで実現 • アプリケーションの実装が複雑 • 再送処理を自前で実装 • 同期処理でメール送信しているので重い • メールで通知する必要のないメッセージも多数 • アプライアンスは保守作業が面倒 • 可用性の確保 • ソフトウェアのアップデート、保守契約更新 • アプリケーション側の実装が複雑で最適でない • メンテナンスが大変 Problem
67. 66 SMTPサーバの運用自体をなくしたい • サービスとしてはメールが送信できればいいだけ。 • SMTPサーバを自前で運用する必然性はない。 • 外部サービスを使うことに決定。 • 同時にメール送信処理をリファクタリング • SendGridに移行！ • メール送信は非同期処理に! • 必要のないメールは廃止 or Slackに移行! Solution
68. 67 SendGridとは • メール配信サービス • アプリケーションはWeb API経由でメール送信できる。 • SMTPを使わずに済む。 • 日本での事例も多い。 • 携帯キャリアの独自の制限を考慮した配信アルゴリズム になっているはず。 • 日本に正規代理店もある。
69. 68 メール送信基盤を開発 アプリケーション AWS SQS AWS EC2 AWS DynamoDB メールをキューに詰める キューから メールを取得 送信したメールを保存 APIをコールして送信実行 カスタマーサポートスタッフ 必要に応じて履歴を確認
70. 69 メール送信基盤を開発 • すべてのアプリケーションが使えるメール配信基盤を開発 • アプリケーションは所定のフォーマットのjsonをキューに詰め るだけ。 • あとは配信基盤がすべての処理を行ってくれる。 • メールの配信 • 配信ステータスの更新 • バウンス対応 Good ✓ アプリケーションがシンプルに! ✓ 運用も簡単に!
71. 70 参考資料 • メール配信基盤の開発と運用について • https://speakerdeck.com/minato128/ikyu-mail-platform • https://user-first.ikyu.co.jp/entry/2017/12/05/000000 • SendGridの活用方法 • https://user-first.ikyu.co.jp/entry/2018/06/06/142759
72. 71 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング
73. 72 • ハードウェア運用管理が難しい。 • 属人的になってしまう。 • 調達に時間がかかる。 • 調達から本番投入まででトータル2ヶ月くらいかかる。 • ライフサイクル（製品寿命）に振り回される。 • ファームウェアのアップデートしたら障害発生 • 利用していたストレージのベンダが倒産して調達不可能に。 データベースサーバ 移行前の課題 • 運用に作業工数がかかりすぎる。 • 増強に時間がかかる。 Problem
74. 73 AWS EC2でSQL Serverのクラスタを構築 Good ✓ 意思決定から1週間程度でサーバの増強が可能に!
75. 74 詳細はブログで公開中 • https://user-first.ikyu.co.jp/entry/sql-server-aws-1 • https://user-first.ikyu.co.jp/entry/sql-server-aws-2 • 移行の背景、方針、移行当日の生々しい話はブログで!
76. 75 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング
77. 76 クラウドサービスのメトリクスはDatadog • クラウドサービスの各種メトリクスのモニタリングはDatadog • AWSの各種サービスとのインテグレーション機能が豊富 • すべてのアプリケーションサーバにスクリプトでインストール • 通知はすべてSlackのアラートチャンネルに送信 • アラートチャンネルには全エンジニアがJoin
78. 77 アプリケーションの性能はNewRelic • APMサービス • APM = Application Performance Monitoring • アプリケーションの性能指標を細かく追跡できる。 • KPIを定めて性能が劣化したらSlackに通知する。 • 有償版を導入して、SQLのトレースも活用 • 性能モニタリングのサービスだが障害調査にも有用 • アプリ内部の急激な速度劣化をグラフで表してくれる。 • 急激にトラフィックが伸びているエンドポイントを示してくれる。
79. 78 まとめと現状の課題、今後の取り組み まとめ 現状の課題、今後の取り組み
80. 79 まとめ
81. 80 • SREは障害を未然に防ぐ活動に注力するのが一番合理的 SREは障害を起こさないための活動 トイル撲滅しなきゃ ポストモーテム 書かなきゃ オンコール対応だ！ 自動化だ！ インシデント管理 しなきゃ SLOを作成しなきゃ
82. 81 障害を起こさないための最適な手段に注力する トイル撲滅しなきゃ ポストモーテム 書かなきゃ オンコール対応だ！ 自動化だ！ インシデント管理し なきゃ SLOを作成しなきゃ 障害を未然に防ぐための手段 • 障害を防ぐために最も効果的な手段にリソースを集中投下する。 • 全部やろうとしない。
83. 82 障害を未然に防ぐ活動 = ソフトウェアエンジニアリング にする! • ソースコード修正でエンジニアリングが完結するメリットは大きい。 • 作業のオーバーヘッドが少なくなる。 • SREに巻き込めるエンジニアの数が多くなる。 • プロダクトのコードの修正もしやすくなる。 • クラウドやSaaSを活用すればソースコード修正で完結できる。 • コードをGitHubなどのリポジトリで管理。 • テストとデプロイを外部CI/CDサービスで実行。 • ただし、適切に活用する。 • 自分たちの考えやプロダクトをクラウド側の特性に合わせる。 • クラウドの利点を最大限活用する。
84. 83 Betterな姿を探るには • Betterな姿を具体的に描くのは難しい。 • 課題は感じるけれど「どうなったらいいのか」は曖昧 クラウドの利点を最大限活用できるサービス基盤 サービス基盤のBetterな姿 • Betterな姿を探るには • 技術、サービス、方法論が解決しようとしている課題を把握 する。 • その課題と自分たちの課題を突き合わせる。 一休の場合
85. 84 大きなプロジェクトの効能 • Infrastructure as CodeやBe Statelessなどはクラウドに移行し なくても実践できる。 • が、実際には難しい。 • 既存の開発案件の流れの中でやるのは大変 • 大きなプロジェクトに携わると視点が切り替わる。 • この機能、使っているんだっけ。 • この運用作業、やってる理由は？ • 大きいはプロジェクトは普段できない課題解決の実行チャンス • ひとつのアイディアで複数の課題を解決する。
86. 85 まとめと現状の課題、今後の取り組み まとめ 現状の課題、今後の取り組み
87. 86 今のままの体制で大丈夫？ システム本部 Application Platform SRE • サービスの成長、新サービスのローンチでSREの占める割合 が大きくなってくる。 人を増やそう。専任者を置こう。 or コードを書いて解決するべし。 人手がかからないサービス基盤にしたのだから バランスを取る必要あり
88. 87 ボトルネックのない開発体制、開発環境を目指す システム本部 Application Platform SRE 宿泊事業本部 プロダクト開発部 レストラン事業本部 プロダクト開発部 支援 支援
89. 88 ボトルネックのない開発体制、開発環境を目指す システム本部 Application Platform SRE 宿泊事業本部 プロダクト開発部 レストラン事業本部 プロダクト開発部 支援 支援 事業展開のボトルネック になっちゃダメ
90. 89 ボトルネックのない開発体制、開発環境を目指す • 新サービスの環境に時間がかかる。 • Elastic Beanstalkは便利だけど設定が煩雑。 • ビルド/デプロイ、スケールアウトにかかる時間を短縮できないか。 • 開発者のローカルの開発環境セットアップをもっと簡単にしたい。 • DockerやKubernetesなどコンテナ技術で改善できないか
91. 90 プロダクトの品質を維持するための基盤作り 総インシデント数 内インフラ起因のインシデント数 2017年上半期 20 6 2017年下半期 12 4 2018年上半期 10 0 2018年下半期 16 0 • プロダクト起因のインシデントが多い。 • フロントエンド(js,css)開発の比重が高まっている。 • モニタリング、品質保証基盤がこの変化に追いつけていない。 • プロダクトの進化に寄り添った品質保証基盤の構築
92. 91 ご清聴ありがとうございました