Laravel×DevOps －インフラ構築の自動化から運用ログの監視まで－
•Télécharger en tant que PPTX, PDF•
2 j'aime•3,552 vues
2019/05/08(水)に開催された『【シューマイ】Tech Lead Engineerから最新技術を学べ！Laravel編』の資料です。 https://shuuu-mai.connpass.com/event/127158/ 概要: 新卒向け逆求人就活サービス『キミスカ』の事例をもとに、Laravelのアーキテクチャ、インフラ構成、デプロイフロー、ログ監視体制についてご紹介をしたいと思います。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Laravel×DevOps －インフラ構築の自動化から運用ログの監視まで－
Similaire à Laravel×DevOps －インフラ構築の自動化から運用ログの監視まで－ (20)
Plus de Shinichiro Yoshida
Plus de Shinichiro Yoshida (20)
Dernier
Dernier (12)
Laravel×DevOps －インフラ構築の自動化から運用ログの監視まで－
- 1. http://www.free-powerpoint-templates-design.com Laravel×DevOps －インフラ構築の自動化から運用ログの監視まで－ 2019/5/8(水) @ シューマツワーカー シューマイ Laravel編 株式会社スタジオ・アルカナ / 株式会社ナシエルホールディングス CTO 吉田 紳一郎
- 2. 自己紹介 • 吉田 紳一郎(35) • (株)スタジオ・アルカナ 取締役(CTO) • (株)ナシエルホールディングス 取締役(CTO) • 趣味で、IPA プロジェクトマネージャ, アプリケーションエンジニア, データベーススペシャリスト, ネットワークスペシャリスト, 情報セ キュリティスペシャリスト保有 • むすこ(10)むすめ(6)保有 • むすこがScratchでゲーム作ってて手伝ったところ「パパのつけたココ の変数名わかりにくいよねぇ。」と独り言を言われて手抜きで手伝っ たことを見透かされていたことが平成最後のかなしみです。
- 3. スタジオ・アルカナ グローアップ ホクトシステム M&A Properties 株式会社ナシエルホールディングス (Naciel Holdings, Inc.) 持株会社 店舗不動産 /M&A ソリューション 店舗不動産 情報提供 飲食・不動産・ 新卒 人材紹介 システム開発 人 材 × 店 舗 × M & A IT 総合サービスプラットフォーム https://naciel-holdings.co.jp/ https://www.s-arcana.co.jp/ https://grow-up1.co.jp/ https://www.hoct.co.jp/ https://ma.maproperties.co.jp/ 企業紹介
- 5. 『キミスカ』とは？01
- 6. • 新卒向けの逆求人プラットフォーム • 通常の採用媒体のフロー • 企業が求人情報を出稿し、学生が企業を探して応募 • キミスカのフロー • 学生が自身の自己PRを書き、企業が学生を探してスカウト https://kimisuka.com/
- 8. 使用技術／ツール02
- 9. 使用技術/ツール Amazon Web Service キミスカのインフラはすべてAWSで 構築されています。 Chef AWS上のサーバー構築はChefによって 自動的なプロビジョニングができる 構成になっています。 Laravel アプリケーションはPHPで開発し、 フレームワークはLaravelを採用しています。 PhpStorm ローカルの開発環境はPhpStormを 使用しています。 Cacoo by nulab インフラの構成図などダイアグラムを 記述するツールとしてCacooを使用しています。 Backlog by nulab プロジェクト管理にはBacklogを使用しています。 ドキュメンテーションはWikiに記載し、 SCMはGitリポジトリを使用しています。 他にもありますが割愛
- 12. 発生しうる課題 ルーティング コントローラビュー モデル DB コントローラーの肥大化 バリデーションの複雑化 RDBとの高い結合度 ビジネスロジック肥大化 トランザクション制御 重複したコード
- 13. どうやって解決する？
- 14. Laravelのコンポーネントを拡張し、責務を明確にする • サービスレイヤーを導入 • → ビジネスロジックの責務を負う • リポジトリレイヤーを導入 • → RDBへの依存度を抽象化する レイヤーの概念を導入し、責務を明確にする • バリデーションを実行する責務をどこに置く？ • → Requestクラスを拡張して責務を負う • 権限チェックなど認証認可の処理はどこに置く？ • → Middlewareがその責務を負う • ヘッダーやフッターの共通処理はどこに記述する？ • → ViewComposerがその責務を負う
- 15. アーキテクチャ構造を拡張した設計 Router Controller Response Model KVS Client UI Application Domain Data Source RDB Search Engine Object Storage Request View Middlewaer ViewComposer Model LayerRepository LayerService Layer RepositoryService artisan Command 業務特性に応じてドメインモデルを設計
- 17. エンタープライズアプリケーションアー キテクチャパターン(PoEAA) • マーチン・ファウラー氏によるエンタープラ イズアプリケーションを設計する上でのアーキ テクチャのカタログ。 • 日本語版は2005年に出版された本だが、書か れている考え方は現在も通用する。 • 抽象的な言葉が連発されるので非常に読み解 きにくい。 • 一言で表すと「関心事に沿ってレイヤー定義 して分離させていこうぜ」というノリ。
- 18. Service Layer エンタープライズアプリケー ションアーキテクチャパターン に掲載れているパターンのひと つ。 “一連の利用可能な操作を確立 し、各操作でアプリケーション の応答を調整する一連のサービ スで、アプリケーションの境界 を定義します。” https://martinfowler.com/eaaCata log/serviceLayer.html
- 19. Repository エンタープライズアプリケー ションアーキテクチャパターン に掲載れているパターンのひと つ。 “ドメインオブジェクトにアク セスするためのコレクションの ようなインターフェイスを使用 して、ドメインとデータマッピ ングレイヤ間を仲介します。” https://martinfowler.com/eaaCata log/repository.html
- 20. インフラ構成04
- 21. インフラ構成 • インフラは、ほぼすべてAWSで構成 • AWSには、ステージング環境と本番環境がある • ローカル開発環境はメンバー全員が同じ構成 • ローカル環境、ステージング環境、本番環境、すべて共通化さ れたChefレシピで自動的に環境が構築される • 年度ごとにサーバーを分離しているため、毎年あたらしい施策 を適用しやすい • 毎年インフラは使い捨て、技術的負債が生まれにくくしている
- 22. 本番環境・ステージング環境 ・DNSはRoute53で管理 ・ELBで負荷分散しつつSSL Terminate ・SSL証明書はACMで発行＆管理 ・アプリケーションはEC2で稼働 ・静的コンテンツはNginxで返却 ・動的コンテンツはApacheにリバースプロキシ ・DBはEC2上にMySQLを構築している ・RDSだと細かい調整がしにくいため自前で構築 ・リードレプリカとしてSlaveも用意 ・参照系のクエリはSlaveへ流している ・サーバーはOpsWorksを使って自動構築 ・バージョンはChef 12の方で運用中 ・コードのデプロイは全てOpsWorks経由 ・画像の保存はStorageGatewayを使用 ・過去の仕様に引きずられてしぶしぶNFS ・本来はS3のみで完結させたい ・メールはSES経由で送信している ・その他、外部連携サービスもあるが割愛 ・安定志向なのでEC2で稼働させているが、 そのうちECS/Fargateに移行していきたい BacklogのGitリポジトリ ・コード管理はBacklogのGitリポジトリを活用 ・Git flowに準拠した開発フローを採用している ・Source Treeを使ってる人が多い ・CloudWatchでエラー拾ったらBacklogに自動で起票 ローカル開発環境 ・Vagrantで差異のない環境を用意 ・Chefレシピは本番環境と共用している ・vagrant-omnibusプラグインを使っている
- 23. デプロイフロー05
- 24. 開発からデプロイまでの流れ • 開発のフローは基本的にgitflowに準拠 • ローカル環境でfeatureブランチを作成 • 開発完了後GitにコミットしBacklogでプルリクエスト • 実装に問題なければdevelopにマージ • developにマージすると自動的にステージング環境へデプロイ • OpsWorks API経由でデプロイを実行し • デプロイマンというSlack botがデプロイを通知 • ステージング環境で問題なければ、masterへマージ • 本番環境へデプロイ • 本番環境へのデプロイは手動でOpsWorksから実行している
- 27. Backlog API Gateway経由で Lambda関数を 呼び出す AWS Lambda 自動デプロイの流れ AWS OpsWorks OpsWorks API 経由でデプロイ Amazon EC2 EC2インスタンスへ デプロイを指示 Slackへ通知 Slack Engineer Chef のdeployレシピを使用している https://docs.chef.io/resource_deploy.html
- 29. 運用ログ監視06
- 30. 監視している運用ログ • Laravelデフォルトのログ(storage/logs/laravel.log) • リクエストログ(HTTPリクエスト情報を記録しているログ) • メール送信ログ（メール送信ステータスを記録しているログ） • Apacheエラーログ • Nginxエラーログ • MySQLエラーログ • CPU使用率 • メモリ使用率 • ディスク使用率
- 31. 通常アラートと緊急アラート • 通常アラートはメール通知 • サービスがダウンする恐れのないエラー • 冗長化されているインスタンスが1台落ちた、など • 発生する頻度が低く影響範囲の狭いエラー • LaravelにExceptionログが記録された、など • 緊急アラートはSlack通知 • サービスダウンが発生する可能性の高いエラー • CPU使用率が高い、メモリが枯渇、ディスク容量が枯渇、など
- 32. 通常アラート • 通常アラートはCloudWatchで監視 • アラートが発生するとBacklogに課題を登録 • 課題が登録されると個別にメールで届く
- 33. Amazon CloudWatch Amazon EC2 CloudWatch Logsへ ログを送信 Amazon Simple Notification Service Alarm アラーム発生で SNSへ通知 Lambda関数を 呼び出す Backlogに 課題を起票 Backlog Engineer メールで通知 AWS Lambda Stacktrace 取得 通常アラート通知の流れ
- 35. Controller --> Service --> Repository --> Model と アプリケーションのアーキテクチャが統一されているので、 スタックトレースを見ただけで該当箇所や担当者の察しがつく
- 36. ユーザーID、発生したURL、リファラー、HTTPリクエ ストパラメーター、HTTPヘッダー、クッキーなどの情 報もログから採取して起票されるため、どのような条 件でエラーが発生したかトレースも可能
- 37. Laravelのログにエラーが吐き出されたら自動的にBacklogにログ内容を記載したチケットを作成する #sa_study 詳しくは社内勉強会でシェアされた資料があるので参照してみてください
- 39. Amazon CloudWatch Amazon EC2 Slack AWS Lambda CloudWatch Logsへ ログを送信 Amazon Simple Notification Service Alarm アラーム発生で SNSへ通知 Lambda関数を 呼び出す Slack APIで アラートを送信 Slackで即時通知 Engineer 緊急アラート通知の流れ
- 42. まとめ
- 43. まとめ • Laravelアーキテクチャ、インフラ構成、デプロイフロー、ログ 監視体制について紹介しました。 • DevOpsを実現するためには、アプリケーションだけではなく、 ネットワーク、セキュリティ、データベース、サービスマネジ メント、チーム開発体制など、プログラミング言語やフレーム ワーク以外の領域のスキルも必要です。 • 自分が身につけていない領域を考え、少しずつ技術の幅を増や していけば、活躍の場がどんどん広がっていきます！ • ITSS, UISS, ITSS+ などを参考にして、体系的に全体像を俯瞰しながら、 自分のわからない領域を知ることができるかも？
- 44. 参考：ITスキル標準（ITSS）