$30 off During Our Annual Pro Sale. View Details »

一休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. 1 自己紹介 • 徳武 聡 • システム本部 CTO室 所属 •

    入社4年目 • 技術基盤の刷新やサービス運用の改善、SRE(サイトリライアビ リティエンジニアリング)などに携わる。
  2. 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/
  3. 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
  4. 10 エンジニアリング組織の体制 レストラン事業本部 宿泊事業本部 新規事業本部 システム本部 データサイエンス部 プロダクト開発部 10人 3人

    プロダクト開発部 15人 4人 デジタルマーケテイング部 5人 10人 営業部 マーケティング部 営業部 マーケティング部
  5. 12 システム本部のエンジニアは側面から事業部を支援 事業部 システム本部 プロダクト開発部 UI/UX Partner Alliance etc… Application

    Platform SRE 新技術の導入 技術負債の返却 etc リソースプランニング リリースエンジニアリング Devops etc…
  6. 13 一休でのSite Reliability Engineering システム本部 Application Platform SRE • SREという肩書のエンジニアはいない。

    • システム本部のエンジニアがSREという活動を行っている。 • 必要であれば事業部のエンジニアも信頼性改善を行う。 × システム本部 Application Platform SRE 〇
  7. 15 ※ SRE = Site Reliability Engineering • この発表では、 SRE

    = Site Reliability Engineering です。 • Site Reliability Engineerではありません。
  8. 17 そもそもSREとは? “要するに、私たちの仕事はシステム内でのアジリティと 安定性のバランスをとることなのです ” SRE本 第9章 「単純さ」 • アジリティ

    = 素早さ • システム内のアジリティ = システム変更の素早さ = 開発の素早さ • システムの素早い変更とシステムの安定さを両立させるためのエ ンジニアリングを行う。
  9. 18 典型的なSREの活動 ( SRE本 第5章 「トイルの撲滅」より ) 1. ソフトウェアエンジニアリング ➢

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

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

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

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

    • 約10人のエンジニアが携わる。 • 2018年4月に完了。 • 物理サーバを置いていたデータセンターを解約完了。 • Amazon Web Serviceでは賄えない部分もこの機会に積極 的に外部サービスを利用するように変更。
  14. 25 クラウド移行のキモ 1. クラウドサービスのメリット、利便性を最大限享受できるかたち で移行を行う。 ➢ そのために必要なエンジニアリングには積極的に工数を投下する。 ➢ 必要であればプロダクトのコードも積極的に修正。 •

    単に物理的な筐体が仮想マシンになっただけ、という移行には 絶対にしない。 2. この大きなプロジェクトの中で一緒に解消できる技術負債は積 極的に解消していく。
  15. 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だった。
  16. 29 アプリケーションサーバ 移行前の課題 ① • 10台以上のアプリケーションサーバを管理 • 設定変更が必要なら管理者が手動で1台づつ対応 • 例えば、月次のWindows

    Update • 毎月、担当者が全台を手動適用 • 物理サーバなので、何かあればデータセンターに行く必要あり • 変更に時間がかかる。 • 変更できる人が限られている。 • 本質的でない作業に必要以上に時間がとられる。 Problem
  17. 30 アプリケーションサーバ 移行前の課題 ② • モノリシック(Monolithic)なウェブアプリケーション • モノリシック = 一枚岩

    • ひとつのアプリケーションでサービスに関するあらゆる機能を 提供 • 顧客向け機能、施設向け機能、社内オペレータ向け機能が単 一アプリケーションで動作 • ソースコードの参照関係も複雑 • 新任の開発者が変更するソースコードを直感的に把握できない。 • 明らかに過剰スペックの物理サーバ • 関心事が適切に分離できていない。 • 適切なサイジングができていない。 Problem
  18. 32 アプリケーションサーバの課題に対する解決策 • アプリケーションサーバはAWS Elastic Beanstalkに移行 • TerraformでInfrastructure as Codeを実践

    • アプリケーションは大規模リファクタリング • ユーザー単位で分割 • 物理サーバ依存のコードを撲滅 = Be Stateless! • AWSのサービスを積極利用 Solution
  19. 33 AWS Elastic Beanstalkとは • 公式サイトによれば • “AWS Elastic Beanstalk

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

    + AWS Auto Scaling の組み 合わせ • 一定以上の負荷でEC2インスタンスが自動で増える。 • EC2インスタンスが障害を起こしたら自動でLBから外れる。 • 自動で新しいEC2インスタンスがサービスイン • アプリケーションデプロイの仕組みも提供 • ローリングデプロイ、 Blue/Greenなどの仕組みを提供 ✓ インフラ管理の大部分をAWSにお任せできる。 ✓ 物理インフラに比べセットアップがはるかに簡単 Good
  21. 35 Terraform+AMIでInfrastructure as Codeを実践 • AMI(Amazon Machine Image)はEC2インスタンスのテンプ レート。カスタマイズ可能 •

    TerraformはInfrastructure as Codeを実践するためのツール • Infrastructure as Codeとは • ソフトウェア開発の手法でインフラを管理する。 • インフラ構成を宣言的でコードで記述できる。 • コードなのでテストができる。 • コードなのでGitHubで管理できる。
  22. 37 すべての作業をコード変更で! • インフラ変更に関するすべての作業をソースコードの修正 + CI/CDで実現 • CI/CDにcircleciを活用 • GitHubのPull

    Requestのマージをトリガにデプロイ開始 • Elastic Beanstalkが変更適用済のEC2を自動的に立ち上げて サービスイン • 変更適用前のEC2は自動的に破棄。サービスは無停止 Good ✓ コードの修正だけで変更を実現 ✓ 物理インフラに比べセットアップがはるかに簡単
  23. 38 アプリケーション大規模リファクタリング① アプリ分割 • 移行プロジェクトで最も工数を費やした作業 • 分割しないとElastic Beanstalkが使えない。 • デプロイパッケージのサイズに上限があるから

    • この機会にソースコードの見通しを良くしたい。 • ついでにデッドコード、不要な機能を削除 • 顧客向け機能、施設向け機能、社内オペレータ向け機能を別の アプリケーションとして分離 Good ✓ コードがより簡単に理解できるようになった。 ✓ デプロイパッケージの作成も簡単になった。
  24. 40 アプリケーション大規模リファクタリング② Be Stateless! • アプリケーションサーバはいつ破棄されても大丈夫にする。 • Disposable(破棄可能) = Immutable(不変)

    • 一度構築したサーバの設定、ソフトウェアは変更しない。 • 変更するなら新しいサーバを作って古いのを破棄 • DisposableならStateless (状態を持たない) にする必要あり • 状態 = アプリ実行で生まれる、アプリ実行に必要な情報 • データベースサーバはStateful = 破棄できない。 • アプリケーションサーバはStatelessにできる。そうするべき。 • そのほうがアプリケーションがシンプルになる。 • 管理もしやすい。
  25. 42 一休のアプリは状態を持っていた • サーバのアクセスログを日時で集計してアクセス解析していた。 • サーバを破棄したらログがなくなってしまう。 ✓ 機能を棚卸しして不要な集計を廃止 ✓ Google

    Analyticsのデータから集計 • アプリが生成したファイルを同期ツールを使って全アプリサー バに配布してダウンロードできるようにしていた。 • サーバを破棄したらファイルがなくなり404になってしまう。 ✓ ファイルをAWS S3にアップロード Good ✓ アプリケーションがシンプルになった。
  26. 43 アプリケーション大規模リファクタリング③ AWS積極活用 • データセンターのファイルサーバはS3に移行 • GitHub管理する必要のない画像ファイルもS3へ • リポジトリのサイズを小さく •

    画像へのリクエストをS3にオフロード • AWS Elasticache Redisでデータのキャッシュ • データベースの負荷軽減 • 応答の高速化 Good ✓ リポジトリが小さくなって開発スピードが向上した。 ✓ アプリケーションサーバ、データベースサーバの負荷軽減
  27. 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
  28. 46 ビルド/デプロイパイプライン 移行前の課題 • 頻繁にデプロイが失敗する。 • デプロイセット作成でエラー発生。 • デプロイフローの途中で止まる。 •

    リリース当番のエンジニアがマニュアルでトラブル対応 • リリースは事業部のエンジニアが当番制で担当している。 • 本来やるべき自分の仕事ができない。
  29. 47 ビルドデプロイパイプライン なぜ不安定? • デプロイスクリプトが複雑で独自 • ロードバランサ、ファイル同期ソフトと連携して自前でカナリ アリリースを実現 • 変更分のみのデプロイを実現するため差分を抽出

    • トラブル対応に多くの知識が必要で時間がかかる。 • ファイル同期ソフトが不安定 • 商用ソフトウェアだが動作不良になるケースがある。 • ビルドデプロイパイプラインが独自過ぎる。 Problem
  30. 48 移行前のビルド/デプロイフロー ロードバランサー アプリケーションサーバ ファイル同期ツール ロードバランサから切り離す API経由で操作 • デプロイセットの作成 •

    ビルド • 変更差分の抽出 • ロードバランサの操作 • 対象サーバの切り離し • デプロイセットの配置 • ファイル同期ツールの一時停止 一時停止 一時停止
  31. 53 デプロイはElastic Beanstalkにお任せ • CI/CDはデプロイパッケージを作成してElastic Beanstalkにデプ ロイ指示をするだけ。 • デプロイ自体はElastic Beanstalkが安全に実行してくれる。

    • ロードバランサからサーバの切り離し • 資材のデプロイとヘルスチェック • Elastic Beanstalkのデプロイパッケージ(zip)は512MB以下に する必要あり。 • 不要なコードを徹底的に削除 • 画像はなるべくS3に配置してデプロイパッケージから排除 • デプロイスクリプトも可能な限りシンプルに。
  32. 57 ロードバランサー 移行前の課題 • アプライアンスを利用 • トラフィックの制御のルールがバージョン管理されていない。 可読性も悪い。 • 変更も手作業

    • 特定のエンジニアしか変更できない。 • アプライアンスは保守作業が大変 • ソフトウェアのアップデート • 保守契約の更新 • トラフィック制御のルールがわかりにくい • メンテナンスが大変 Problem
  33. 58 移行先を検討! • [案1]自前でnginxを立てて運用する。 • 可用性も自分たちで担保する必要がある。 • 設計が複雑になりそう。 • マネージドなサービスを活用したい。

    • [案2] AWS Application Load Balancerに移行 • 既存のトラフィック制御のルールが完全に移植できない。 • オリジンサーバ側のリライト処理も修正が必要 • 工数がかかりそう。
  34. 60 Fastlyとは • CDN = コンテンツ配信ネットワーク • 効率的かつ高速にコンテンツを届ける仕組み • HTTPアクセラレータであるVarnishを利用している。

    • Varnish = キャッシュ機構搭載のリバースプロキシ • VCL(Varnish Configuration Language)で柔軟にルーテ ィングできる。 • 大規模なサービスも使っているので信頼性も高そう。 • Fastlyに移行! Solution
  35. 63 アプリケーション開発にも積極的活用 • 新機能の部分リリース • 特定のパラメータがあるときだけ新機能を有効にする。 • VCLファイルのデプロイが高速なので簡単に実験できる。 • リクエスト追跡IDを付与

    • VCLでリクエストヘッダにユニークIDを付与 • アプリケーションログや各種メトリクスにユニークIDを出力 • リクエスト単位での調査がやりやすくなった。 Good ✓ 誰でもルーティングの定義が変更できる。 ✓ アプリケーション開発でも積極的活用 ✓ キャッシュ機構活用でサイトの信頼性アップ
  36. 65 メールサーバー 移行前の課題 • Windows Serverのメールサーバ機能とアプライアンスで実現 • アプリケーションの実装が複雑 • 再送処理を自前で実装

    • 同期処理でメール送信しているので重い • メールで通知する必要のないメッセージも多数 • アプライアンスは保守作業が面倒 • 可用性の確保 • ソフトウェアのアップデート、保守契約更新 • アプリケーション側の実装が複雑で最適でない • メンテナンスが大変 Problem
  37. 67 SendGridとは • メール配信サービス • アプリケーションはWeb API経由でメール送信できる。 • SMTPを使わずに済む。 •

    日本での事例も多い。 • 携帯キャリアの独自の制限を考慮した配信アルゴリズム になっているはず。 • 日本に正規代理店もある。
  38. 68 メール送信基盤を開発 アプリケーション AWS SQS AWS EC2 AWS DynamoDB メールをキューに詰める

    キューから メールを取得 送信したメールを保存 APIをコールして送信実行 カスタマーサポートスタッフ 必要に応じて履歴を確認
  39. 72 • ハードウェア運用管理が難しい。 • 属人的になってしまう。 • 調達に時間がかかる。 • 調達から本番投入まででトータル2ヶ月くらいかかる。 •

    ライフサイクル(製品寿命)に振り回される。 • ファームウェアのアップデートしたら障害発生 • 利用していたストレージのベンダが倒産して調達不可能に。 データベースサーバ 移行前の課題 • 運用に作業工数がかかりすぎる。 • 増強に時間がかかる。 Problem
  40. 77 アプリケーションの性能はNewRelic • APMサービス • APM = Application Performance Monitoring

    • アプリケーションの性能指標を細かく追跡できる。 • KPIを定めて性能が劣化したらSlackに通知する。 • 有償版を導入して、SQLのトレースも活用 • 性能モニタリングのサービスだが障害調査にも有用 • アプリ内部の急激な速度劣化をグラフで表してくれる。 • 急激にトラフィックが伸びているエンドポイントを示してくれる。
  41. 81 障害を起こさないための最適な手段に注力する トイル撲滅しなきゃ ポストモーテム 書かなきゃ オンコール対応だ! 自動化だ! インシデント管理し なきゃ SLOを作成しなきゃ

    障害を未然に防ぐための手段 • 障害を防ぐために最も効果的な手段にリソースを集中投下する。 • 全部やろうとしない。
  42. 82 障害を未然に防ぐ活動 = ソフトウェアエンジニアリング にする! • ソースコード修正でエンジニアリングが完結するメリットは大きい。 • 作業のオーバーヘッドが少なくなる。 •

    SREに巻き込めるエンジニアの数が多くなる。 • プロダクトのコードの修正もしやすくなる。 • クラウドやSaaSを活用すればソースコード修正で完結できる。 • コードをGitHubなどのリポジトリで管理。 • テストとデプロイを外部CI/CDサービスで実行。 • ただし、適切に活用する。 • 自分たちの考えやプロダクトをクラウド側の特性に合わせる。 • クラウドの利点を最大限活用する。
  43. 84 大きなプロジェクトの効能 • Infrastructure as CodeやBe Statelessなどはクラウドに移行し なくても実践できる。 • が、実際には難しい。

    • 既存の開発案件の流れの中でやるのは大変 • 大きなプロジェクトに携わると視点が切り替わる。 • この機能、使っているんだっけ。 • この運用作業、やってる理由は? • 大きいはプロジェクトは普段できない課題解決の実行チャンス • ひとつのアイディアで複数の課題を解決する。
  44. 90 プロダクトの品質を維持するための基盤作り 総インシデント数 内インフラ起因のインシデント数 2017年上半期 20 6 2017年下半期 12 4

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