Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

s-tokutake
January 30, 2019

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

s-tokutake

January 30, 2019
Tweet

More Decks by s-tokutake

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  4. 3
    一休の紹介

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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/

    View full-size slide

  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

    View full-size slide

  10. 9
    開発組織について

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  15. 14
    一休でのSite Reliability Engineering

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide