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

by s-tokutake

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

1 自己紹介 • 徳武聡 • システム本部 CTO室所属 • 入社4年目 • 技術基盤の刷新やサービス運用の改善、SRE(サイトリライアビリティエンジニアリング)などに携わる。

Slide 3

Slide 3 text

2 本日の内容 一休の紹介 開発組織について 一休でのSite Reliability Engineering クラウド移行プロジェクト 具体的な移行事例 今後の取り組みとまとめ

Slide 4

Slide 4 text

3 一休の紹介

Slide 5

Slide 5 text

4 一休について • 1998年7月30日設立 • 2016年ヤフーグループ入り • 従業員数 339名 (2018年7月現在) • エンジニアは約50名

Slide 6

Slide 6 text

5 一休.com • 上質な宿泊施設予約 • 2000年誕生 • 会員数800万人超 • 高い成長率を維持

Slide 7

Slide 7 text

6 一休.comレストラン • ファインダイニング予約 • 2006年誕生 • 高い成長率を維持

Slide 8

Slide 8 text

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/

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

9 開発組織について

Slide 11

Slide 11 text

10 エンジニアリング組織の体制レストラン事業本部宿泊事業本部新規事業本部システム本部データサイエンス部プロダクト開発部 10人 3人プロダクト開発部 15人 4人デジタルマーケテイング部 5人 10人営業部マーケティング部営業部マーケティング部

Slide 12

Slide 12 text

11 事業部のエンジニアは目的型組織でミッションを追う事業本部システム本部プロダクト開発部 UI/UX Partner Alliance etc… Application Platform SRE

Slide 13

Slide 13 text

12 システム本部のエンジニアは側面から事業部を支援事業部システム本部プロダクト開発部 UI/UX Partner Alliance etc… Application Platform SRE 新技術の導入技術負債の返却 etc リソースプランニングリリースエンジニアリング Devops etc…

Slide 14

Slide 14 text

13 一休でのSite Reliability Engineering システム本部 Application Platform SRE • SREという肩書のエンジニアはいない。 • システム本部のエンジニアがSREという活動を行っている。 • 必要であれば事業部のエンジニアも信頼性改善を行う。 × システム本部 Application Platform SRE 〇

Slide 15

Slide 15 text

14 一休でのSite Reliability Engineering

Slide 16

Slide 16 text

15 ※ SRE = Site Reliability Engineering • この発表では、 SRE = Site Reliability Engineering です。 • Site Reliability Engineerではありません。

Slide 17

Slide 17 text

16 この発表を通して伝えたいこと ✓ SREはソフトウェアエンジニアリングを通じて障害を未然に防ぐことに注力することで最大の価値が提供できる。 ✓ そのためには、可能な限りのあらゆる成果物をソフトウェアエンジニアリング=コーディングで生み出せるようにしておく。 ✓ そのために、クラウドや外部サービスを積極的に活用する。 ✓ 障害を未然に防ぐためのエンジニアリングに最大限注力する。

Slide 18

Slide 18 text

17 そもそもSREとは? “要するに、私たちの仕事はシステム内でのアジリティと安定性のバランスをとることなのです ” SRE本第９章「単純さ」 • アジリティ = 素早さ • システム内のアジリティ = システム変更の素早さ = 開発の素早さ • システムの素早い変更とシステムの安定さを両立させるためのエンジニアリングを行う。

Slide 19

Slide 19 text

18 典型的なSREの活動 ( SRE本第5章「トイルの撲滅」より ) 1. ソフトウェアエンジニアリング ➢ コードの作成や修正を含む作業。 • 自動化スクリプトの作成、ツールやフレームワークの作成。 2. システムエンジニアリング ➢ プロダクションシステムの設定、設定の変更。 • サーバセットアップ。モニタリングのセットアップ。 • ロードバランサの設定。各種パラメータチューニングなど。 3. トイル ➢ サービスを稼働させるのに直結している作業で、繰り返されたり、手作業だったりするもの 4. オーバヘッド ➢ 管理作業。採用や事務作業、ミーティング、評価など。

Slide 20

Slide 20 text

19 1. ソフトウェアエンジニアリング ➢ コードの作成や修正を含む作業。 • 自動化スクリプトの作成、ツールやフレームワークの作成。 2. システムエンジニアリング ➢ プロダクションシステムの設定、設定の変更。 • サーバセットアップ。モニタリングのセットアップ。 • ロードバランサの設定。各種パラメータチューニングなど。 3. トイル ➢ サービスを稼働させるのに直結している作業で、繰り返されたり、手作業だったりするもの 4. オーバヘッド ➢ 管理作業。採用や事務作業、ミーティング、評価など。一休では2年前までは… 技術基盤エンジニアが担当ビルド&リリーススクリプトの開発開発環境の整備インフラエンジニアが担当物理サーバのセットアップハードウェアメンテナンス

Slide 21

Slide 21 text

20 1. ソフトウェアエンジニアリング ➢ コードの作成や修正を含む作業。 • 自動化スクリプトの作成、ツールやフレームワークの作成。 2. システムエンジニアリング ➢ プロダクションシステムの設定、設定の変更。 • サーバセットアップ。モニタリングのセットアップ。 • ロードバランサの設定。各種パラメータチューニングなど。 3. トイル ➢ サービスを稼働させるのに直結している作業で、繰り返されたり、手作業だったりするもの 4. オーバヘッド ➢ 管理作業。採用や事務作業、ミーティング、評価など。作業内容の隔たりが大きかった技術基盤エンジニアが担当ビルド&リリーススクリプトの開発開発環境の整備インフラエンジニアが担当物理サーバのセットアップハードウェアメンテナンス大きな壁作業内容の分断属人化

Slide 22

Slide 22 text

21 1. ソフトウェアエンジニアリング ➢ コードの作成や修正を含む作業。 • 自動化スクリプトの作成、ツールやフレームワークの作成。 2. システムエンジニアリング ➢ プロダクションシステムの設定、設定の変更。 • サーバセットアップ。モニタリングのセットアップ。 • ロードバランサの設定。各種パラメータチューニングなど。 3. トイル ➢ サービスを稼働させるのに直結している作業で、繰り返されたり、手作業だったりするもの 4. オーバヘッド ➢ 管理作業。採用や事務作業、ミーティング、評価など。今は… 両方ともソフトウェアエンジニアが担当両方ともソフトウェアエンジニアが担当両方ともソースコードの作成、修正で完結できる。壁の解消

Slide 23

Slide 23 text

22 一休でのSite Reliability Engineering • ソースコードの作成、修正でSREが完結する。 • SREに巻き込めるエンジニアの数が増える。 • 専任者への作業集中が防げる。 • エンジニアリングのリソースをより合理的に配置できる。システム本部 Application Platform SRE

Slide 24

Slide 24 text

23 なぜ… なぜソースコードの作成、修正でSREが完結できるようになったのか。

Slide 25

Slide 25 text

24 クラウド移行プロジェクト • 一休のサービスに関するすべてのインフラをクラウドに移行するプロジェクト • Amazon Web Serviceへ移行。2016年末にプロジェクトキックオフ。 • 約10人のエンジニアが携わる。 • 2018年4月に完了。 • 物理サーバを置いていたデータセンターを解約完了。 • Amazon Web Serviceでは賄えない部分もこの機会に積極的に外部サービスを利用するように変更。

Slide 26

Slide 26 text

25 クラウド移行のキモ 1. クラウドサービスのメリット、利便性を最大限享受できるかたちで移行を行う。 ➢ そのために必要なエンジニアリングには積極的に工数を投下する。 ➢ 必要であればプロダクトのコードも積極的に修正。 • 単に物理的な筐体が仮想マシンになっただけ、という移行には絶対にしない。 2. この大きなプロジェクトの中で一緒に解消できる技術負債は積極的に解消していく。

Slide 27

Slide 27 text

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だった。

Slide 28

Slide 28 text

27 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング

Slide 29

Slide 29 text

28 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング

Slide 30

Slide 30 text

29 アプリケーションサーバ移行前の課題 ① • 10台以上のアプリケーションサーバを管理 • 設定変更が必要なら管理者が手動で1台づつ対応 • 例えば、月次のWindows Update • 毎月、担当者が全台を手動適用 • 物理サーバなので、何かあればデータセンターに行く必要あり • 変更に時間がかかる。 • 変更できる人が限られている。 • 本質的でない作業に必要以上に時間がとられる。 Problem

Slide 31

Slide 31 text

30 アプリケーションサーバ移行前の課題 ② • モノリシック(Monolithic)なウェブアプリケーション • モノリシック = 一枚岩 • ひとつのアプリケーションでサービスに関するあらゆる機能を提供 • 顧客向け機能、施設向け機能、社内オペレータ向け機能が単一アプリケーションで動作 • ソースコードの参照関係も複雑 • 新任の開発者が変更するソースコードを直感的に把握できない。 • 明らかに過剰スペックの物理サーバ • 関心事が適切に分離できていない。 • 適切なサイジングができていない。 Problem

Slide 32

Slide 32 text

31 アプリケーションサーバ移行前の課題

Slide 33

Slide 33 text

32 アプリケーションサーバの課題に対する解決策 • アプリケーションサーバはAWS Elastic Beanstalkに移行 • TerraformでInfrastructure as Codeを実践 • アプリケーションは大規模リファクタリング • ユーザー単位で分割 • 物理サーバ依存のコードを撲滅 = Be Stateless! • AWSのサービスを積極利用 Solution

Slide 34

Slide 34 text

33 AWS Elastic Beanstalkとは • 公式サイトによれば • “AWS Elastic Beanstalk により、開発者は AWS クラウドのアプリケーションを迅速にデプロイし管理することがより簡単になります。 ” • “開発者は単にそのアプリケーションをアップロードするだけで、Elastic Beanstalk が自動的に容量のプロビジョニング、負荷分散、Auto- Scaling、およびアプリケーション状態モニタリングといったデプロイの詳細を処理します。” • AWSのPlatform as a Service • アプリケーションに必要なミドルウェアをサービスとして提供する。

Slide 35

Slide 35 text

34 AWS Elastic Beanstalkとは • EC2 + Elastic Load Balancing + AWS Auto Scaling の組み合わせ • 一定以上の負荷でEC2インスタンスが自動で増える。 • EC2インスタンスが障害を起こしたら自動でLBから外れる。 • 自動で新しいEC2インスタンスがサービスイン • アプリケーションデプロイの仕組みも提供 • ローリングデプロイ、 Blue/Greenなどの仕組みを提供 ✓ インフラ管理の大部分をAWSにお任せできる。 ✓ 物理インフラに比べセットアップがはるかに簡単 Good

Slide 36

Slide 36 text

35 Terraform+AMIでInfrastructure as Codeを実践 • AMI(Amazon Machine Image)はEC2インスタンスのテンプレート。カスタマイズ可能 • TerraformはInfrastructure as Codeを実践するためのツール • Infrastructure as Codeとは • ソフトウェア開発の手法でインフラを管理する。 • インフラ構成を宣言的でコードで記述できる。 • コードなのでテストができる。 • コードなのでGitHubで管理できる。

Slide 37

Slide 37 text

36 Windows Updateを適用するなら新AMIをElastic Beanstalkに適用新しいAMIを入手新AMIでTerraformを更新新カスタムAMIを作成

Slide 38

Slide 38 text

37 すべての作業をコード変更で！ • インフラ変更に関するすべての作業をソースコードの修正 + CI/CDで実現 • CI/CDにcircleciを活用 • GitHubのPull Requestのマージをトリガにデプロイ開始 • Elastic Beanstalkが変更適用済のEC2を自動的に立ち上げてサービスイン • 変更適用前のEC2は自動的に破棄。サービスは無停止 Good ✓ コードの修正だけで変更を実現 ✓ 物理インフラに比べセットアップがはるかに簡単

Slide 39

Slide 39 text

38 アプリケーション大規模リファクタリング① アプリ分割 • 移行プロジェクトで最も工数を費やした作業 • 分割しないとElastic Beanstalkが使えない。 • デプロイパッケージのサイズに上限があるから • この機会にソースコードの見通しを良くしたい。 • ついでにデッドコード、不要な機能を削除 • 顧客向け機能、施設向け機能、社内オペレータ向け機能を別のアプリケーションとして分離 Good ✓ コードがより簡単に理解できるようになった。 ✓ デプロイパッケージの作成も簡単になった。

Slide 40

Slide 40 text

39 分割後の構成 Good ✓ 適切なサイジングが可能になった。

Slide 41

Slide 41 text

40 アプリケーション大規模リファクタリング② Be Stateless! • アプリケーションサーバはいつ破棄されても大丈夫にする。 • Disposable(破棄可能) = Immutable(不変) • 一度構築したサーバの設定、ソフトウェアは変更しない。 • 変更するなら新しいサーバを作って古いのを破棄 • DisposableならStateless (状態を持たない) にする必要あり • 状態 = アプリ実行で生まれる、アプリ実行に必要な情報 • データベースサーバはStateful = 破棄できない。 • アプリケーションサーバはStatelessにできる。そうするべき。 • そのほうがアプリケーションがシンプルになる。 • 管理もしやすい。

Slide 42

Slide 42 text

41 一休のアプリは状態を持っていた • サーバのアクセスログを日時で集計してアクセス解析していた。 • サーバを破棄したらログがなくなってしまう。 • アプリが生成したファイルを同期ツールを使って全アプリサーバに配布してダウンロードできるようにしていた。 • サーバを破棄したらファイルがなくなり404になってしまう。

Slide 43

Slide 43 text

42 一休のアプリは状態を持っていた • サーバのアクセスログを日時で集計してアクセス解析していた。 • サーバを破棄したらログがなくなってしまう。 ✓ 機能を棚卸しして不要な集計を廃止 ✓ Google Analyticsのデータから集計 • アプリが生成したファイルを同期ツールを使って全アプリサーバに配布してダウンロードできるようにしていた。 • サーバを破棄したらファイルがなくなり404になってしまう。 ✓ ファイルをAWS S3にアップロード Good ✓ アプリケーションがシンプルになった。

Slide 44

Slide 44 text

43 アプリケーション大規模リファクタリング③ AWS積極活用 • データセンターのファイルサーバはS3に移行 • GitHub管理する必要のない画像ファイルもS3へ • リポジトリのサイズを小さく • 画像へのリクエストをS3にオフロード • AWS Elasticache Redisでデータのキャッシュ • データベースの負荷軽減 • 応答の高速化 Good ✓ リポジトリが小さくなって開発スピードが向上した。 ✓ アプリケーションサーバ、データベースサーバの負荷軽減

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

45 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング

Slide 47

Slide 47 text

46 ビルド/デプロイパイプライン移行前の課題 • 頻繁にデプロイが失敗する。 • デプロイセット作成でエラー発生。 • デプロイフローの途中で止まる。 • リリース当番のエンジニアがマニュアルでトラブル対応 • リリースは事業部のエンジニアが当番制で担当している。 • 本来やるべき自分の仕事ができない。

Slide 48

Slide 48 text

47 ビルドデプロイパイプラインなぜ不安定? • デプロイスクリプトが複雑で独自 • ロードバランサ、ファイル同期ソフトと連携して自前でカナリアリリースを実現 • 変更分のみのデプロイを実現するため差分を抽出 • トラブル対応に多くの知識が必要で時間がかかる。 • ファイル同期ソフトが不安定 • 商用ソフトウェアだが動作不良になるケースがある。 • ビルドデプロイパイプラインが独自過ぎる。 Problem

Slide 49

Slide 49 text

48 移行前のビルド/デプロイフローロードバランサーアプリケーションサーバファイル同期ツールロードバランサから切り離す API経由で操作 • デプロイセットの作成 • ビルド • 変更差分の抽出 • ロードバランサの操作 • 対象サーバの切り離し • デプロイセットの配置 • ファイル同期ツールの一時停止一時停止一時停止

Slide 50

Slide 50 text

49 ビルドデプロイパイプラインの課題に対する解決策 • 動作に必要なすべてのファイルをデプロイ • 差分デプロイをやめるためのエンジニアリングを実施 • Disposableにするには差分デプロイではダメ • ビルドは外部のCIサービスで実行 • Jenkinsをやめるためのエンジニアリングを実施 • デプロイパッケージの仕様は標準に合わせる • デプロイはElastic Beanstalkにお任せ Solution

Slide 51

Slide 51 text

50 差分デプロイをやめよう • なぜ差分デプロイの必要がある？ • サイトのデザイン変更を素早く実現するため • フロントエンドの資材だけ素早くデプロイ • 一休.comはデザインが命 • 変更が高頻度な部分はデプロイ不要で変えられるようにしよう。簡易なCMSを開発

Slide 52

Slide 52 text

51 簡易CMSでバナー変更を楽ちんに! Elasticache Good • jsonをアップロードするだけでバナーを変更できる仕組みを開発 • アプリのデプロイと無関係にデザインを変えられる。 ✓ デザイナーの関心とアプリのデプロイが疎結合に ✓ デザイン変更の工数削減 ✓ 差分デプロイの廃止

Slide 53

Slide 53 text

52 ビルドは外部のサービスで実行 • 外部のCI/CDサービスを利用 • ビルドの定義ファイルをアプリと同じリポジトリで管理できる。 • ビルド環境自体が状態を持たないようになっている。 • 問題が特定しやすい。 • ビルド環境の変更も定義ファイルを変えるだけでOK

Slide 54

Slide 54 text

53 デプロイはElastic Beanstalkにお任せ • CI/CDはデプロイパッケージを作成してElastic Beanstalkにデプロイ指示をするだけ。 • デプロイ自体はElastic Beanstalkが安全に実行してくれる。 • ロードバランサからサーバの切り離し • 資材のデプロイとヘルスチェック • Elastic Beanstalkのデプロイパッケージ(zip)は512MB以下にする必要あり。 • 不要なコードを徹底的に削除 • 画像はなるべくS3に配置してデプロイパッケージから排除 • デプロイスクリプトも可能な限りシンプルに。

Slide 55

Slide 55 text

54 変更後のデプロイフローマージをトリガにビルド開始 APIでデプロイ指示 Windows環境で動作するアプリはAppveyor Linux環境で動作するアプリはcircleci Good ✓ ビルド/デプロイフローが安定 ✓ リリース回数が日次1回から日次3回へアップ

Slide 56

Slide 56 text

55 参考資料 • 一休.comのビルド/デプロイの歴史について • https://speakerdeck.com/kensuketanaka/ikyu-deploy-flow • https://speakerdeck.com/minato128/ikyu-deploy

Slide 57

Slide 57 text

56 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング

Slide 58

Slide 58 text

57 ロードバランサー移行前の課題 • アプライアンスを利用 • トラフィックの制御のルールがバージョン管理されていない。可読性も悪い。 • 変更も手作業 • 特定のエンジニアしか変更できない。 • アプライアンスは保守作業が大変 • ソフトウェアのアップデート • 保守契約の更新 • トラフィック制御のルールがわかりにくい • メンテナンスが大変 Problem

Slide 59

Slide 59 text

58 移行先を検討! • [案1]自前でnginxを立てて運用する。 • 可用性も自分たちで担保する必要がある。 • 設計が複雑になりそう。 • マネージドなサービスを活用したい。 • [案2] AWS Application Load Balancerに移行 • 既存のトラフィック制御のルールが完全に移植できない。 • オリジンサーバ側のリライト処理も修正が必要 • 工数がかかりそう。

Slide 60

Slide 60 text

59 CDNサービス見直しでFastlyを検証してみると • Fastlyはリバースプロキシとして活用できそう。 • 既存のトラフィック制御のルールも移植できる。 • マネージドなサービス • 設定もプログラマブル

Slide 61

Slide 61 text

60 Fastlyとは • CDN = コンテンツ配信ネットワーク • 効率的かつ高速にコンテンツを届ける仕組み • HTTPアクセラレータであるVarnishを利用している。 • Varnish = キャッシュ機構搭載のリバースプロキシ • VCL(Varnish Configuration Language)で柔軟にルーティングできる。 • 大規模なサービスも使っているので信頼性も高そう。 • Fastlyに移行！ Solution

Slide 62

Slide 62 text

61 VCLファイルの変更もInfrastructure As Code VCLファイルはGitHubで管理マージをトリガにしてCIが起動 circleci上でTerraformが適用を実行 AWS Application Load Balancer AWS EC2

Slide 63

Slide 63 text

62 キャッシュ機構も積極的に活用 • ゴールデンタイムのTVで宿泊施設が話題になる。 • 平時の2倍のアクセスが来てトラフィックがスパイク！ • Fastlyキャッシュがコンテンツを返すのでサービスには影響なし

Slide 64

Slide 64 text

63 アプリケーション開発にも積極的活用 • 新機能の部分リリース • 特定のパラメータがあるときだけ新機能を有効にする。 • VCLファイルのデプロイが高速なので簡単に実験できる。 • リクエスト追跡IDを付与 • VCLでリクエストヘッダにユニークIDを付与 • アプリケーションログや各種メトリクスにユニークIDを出力 • リクエスト単位での調査がやりやすくなった。 Good ✓ 誰でもルーティングの定義が変更できる。 ✓ アプリケーション開発でも積極的活用 ✓ キャッシュ機構活用でサイトの信頼性アップ

Slide 65

Slide 65 text

64 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング

Slide 66

Slide 66 text

65 メールサーバー移行前の課題 • Windows Serverのメールサーバ機能とアプライアンスで実現 • アプリケーションの実装が複雑 • 再送処理を自前で実装 • 同期処理でメール送信しているので重い • メールで通知する必要のないメッセージも多数 • アプライアンスは保守作業が面倒 • 可用性の確保 • ソフトウェアのアップデート、保守契約更新 • アプリケーション側の実装が複雑で最適でない • メンテナンスが大変 Problem

Slide 67

Slide 67 text

66 SMTPサーバの運用自体をなくしたい • サービスとしてはメールが送信できればいいだけ。 • SMTPサーバを自前で運用する必然性はない。 • 外部サービスを使うことに決定。 • 同時にメール送信処理をリファクタリング • SendGridに移行！ • メール送信は非同期処理に! • 必要のないメールは廃止 or Slackに移行! Solution

Slide 68

Slide 68 text

67 SendGridとは • メール配信サービス • アプリケーションはWeb API経由でメール送信できる。 • SMTPを使わずに済む。 • 日本での事例も多い。 • 携帯キャリアの独自の制限を考慮した配信アルゴリズムになっているはず。 • 日本に正規代理店もある。

Slide 69

Slide 69 text

68 メール送信基盤を開発アプリケーション AWS SQS AWS EC2 AWS DynamoDB メールをキューに詰めるキューからメールを取得送信したメールを保存 APIをコールして送信実行カスタマーサポートスタッフ必要に応じて履歴を確認

Slide 70

Slide 70 text

69 メール送信基盤を開発 • すべてのアプリケーションが使えるメール配信基盤を開発 • アプリケーションは所定のフォーマットのjsonをキューに詰めるだけ。 • あとは配信基盤がすべての処理を行ってくれる。 • メールの配信 • 配信ステータスの更新 • バウンス対応 Good ✓ アプリケーションがシンプルに! ✓ 運用も簡単に!

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

71 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング

Slide 73

Slide 73 text

72 • ハードウェア運用管理が難しい。 • 属人的になってしまう。 • 調達に時間がかかる。 • 調達から本番投入まででトータル2ヶ月くらいかかる。 • ライフサイクル（製品寿命）に振り回される。 • ファームウェアのアップデートしたら障害発生 • 利用していたストレージのベンダが倒産して調達不可能に。データベースサーバ移行前の課題 • 運用に作業工数がかかりすぎる。 • 増強に時間がかかる。 Problem

Slide 74

Slide 74 text

73 AWS EC2でSQL Serverのクラスタを構築 Good ✓ 意思決定から1週間程度でサーバの増強が可能に!

Slide 75

Slide 75 text

74 詳細はブログで公開中 • https://user-first.ikyu.co.jp/entry/sql-server-aws-1 • https://user-first.ikyu.co.jp/entry/sql-server-aws-2 • 移行の背景、方針、移行当日の生々しい話はブログで!

Slide 76

Slide 76 text

75 具体的な移行事例 アプリケーションサーバ ビルド/デプロイパイプライン ロードバランサー メールサーバ データベースサーバ モニタリング

Slide 77

Slide 77 text

76 クラウドサービスのメトリクスはDatadog • クラウドサービスの各種メトリクスのモニタリングはDatadog • AWSの各種サービスとのインテグレーション機能が豊富 • すべてのアプリケーションサーバにスクリプトでインストール • 通知はすべてSlackのアラートチャンネルに送信 • アラートチャンネルには全エンジニアがJoin

Slide 78

Slide 78 text

77 アプリケーションの性能はNewRelic • APMサービス • APM = Application Performance Monitoring • アプリケーションの性能指標を細かく追跡できる。 • KPIを定めて性能が劣化したらSlackに通知する。 • 有償版を導入して、SQLのトレースも活用 • 性能モニタリングのサービスだが障害調査にも有用 • アプリ内部の急激な速度劣化をグラフで表してくれる。 • 急激にトラフィックが伸びているエンドポイントを示してくれる。

Slide 79

Slide 79 text

78 まとめと現状の課題、今後の取り組み まとめ 現状の課題、今後の取り組み

Slide 80

Slide 80 text

79 まとめ

Slide 81

Slide 81 text

80 • SREは障害を未然に防ぐ活動に注力するのが一番合理的 SREは障害を起こさないための活動トイル撲滅しなきゃポストモーテム書かなきゃオンコール対応だ！自動化だ！インシデント管理しなきゃ SLOを作成しなきゃ

Slide 82

Slide 82 text

81 障害を起こさないための最適な手段に注力するトイル撲滅しなきゃポストモーテム書かなきゃオンコール対応だ！自動化だ！インシデント管理しなきゃ SLOを作成しなきゃ障害を未然に防ぐための手段 • 障害を防ぐために最も効果的な手段にリソースを集中投下する。 • 全部やろうとしない。

Slide 83

Slide 83 text

82 障害を未然に防ぐ活動 = ソフトウェアエンジニアリングにする! • ソースコード修正でエンジニアリングが完結するメリットは大きい。 • 作業のオーバーヘッドが少なくなる。 • SREに巻き込めるエンジニアの数が多くなる。 • プロダクトのコードの修正もしやすくなる。 • クラウドやSaaSを活用すればソースコード修正で完結できる。 • コードをGitHubなどのリポジトリで管理。 • テストとデプロイを外部CI/CDサービスで実行。 • ただし、適切に活用する。 • 自分たちの考えやプロダクトをクラウド側の特性に合わせる。 • クラウドの利点を最大限活用する。

Slide 84

Slide 84 text

83 Betterな姿を探るには • Betterな姿を具体的に描くのは難しい。 • 課題は感じるけれど「どうなったらいいのか」は曖昧クラウドの利点を最大限活用できるサービス基盤サービス基盤のBetterな姿 • Betterな姿を探るには • 技術、サービス、方法論が解決しようとしている課題を把握する。 • その課題と自分たちの課題を突き合わせる。一休の場合

Slide 85

Slide 85 text

84 大きなプロジェクトの効能 • Infrastructure as CodeやBe Statelessなどはクラウドに移行しなくても実践できる。 • が、実際には難しい。 • 既存の開発案件の流れの中でやるのは大変 • 大きなプロジェクトに携わると視点が切り替わる。 • この機能、使っているんだっけ。 • この運用作業、やってる理由は？ • 大きいはプロジェクトは普段できない課題解決の実行チャンス • ひとつのアイディアで複数の課題を解決する。

Slide 86

Slide 86 text

85 まとめと現状の課題、今後の取り組み まとめ 現状の課題、今後の取り組み

Slide 87

Slide 87 text

86 今のままの体制で大丈夫？システム本部 Application Platform SRE • サービスの成長、新サービスのローンチでSREの占める割合が大きくなってくる。人を増やそう。専任者を置こう。 or コードを書いて解決するべし。人手がかからないサービス基盤にしたのだからバランスを取る必要あり

Slide 88

Slide 88 text

87 ボトルネックのない開発体制、開発環境を目指すシステム本部 Application Platform SRE 宿泊事業本部プロダクト開発部レストラン事業本部プロダクト開発部支援支援

Slide 89

Slide 89 text

88 ボトルネックのない開発体制、開発環境を目指すシステム本部 Application Platform SRE 宿泊事業本部プロダクト開発部レストラン事業本部プロダクト開発部支援支援事業展開のボトルネックになっちゃダメ

Slide 90

Slide 90 text

89 ボトルネックのない開発体制、開発環境を目指す • 新サービスの環境に時間がかかる。 • Elastic Beanstalkは便利だけど設定が煩雑。 • ビルド/デプロイ、スケールアウトにかかる時間を短縮できないか。 • 開発者のローカルの開発環境セットアップをもっと簡単にしたい。 • DockerやKubernetesなどコンテナ技術で改善できないか

Slide 91

Slide 91 text

90 プロダクトの品質を維持するための基盤作り総インシデント数内インフラ起因のインシデント数 2017年上半期 20 6 2017年下半期 12 4 2018年上半期 10 0 2018年下半期 16 0 • プロダクト起因のインシデントが多い。 • フロントエンド(js,css)開発の比重が高まっている。 • モニタリング、品質保証基盤がこの変化に追いつけていない。 • プロダクトの進化に寄り添った品質保証基盤の構築

Slide 92

Slide 92 text

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