re:shine 開発基盤の概要

Transcript

1. Naomichi Yamakita re:shine 開発基盤の概要
2. Naomichi Yamakita • Metaps ESC - SRE ◦ Metaps Engineer Steering Committee • Metaps Alpha - インフラエンジニア • pring - リードエンジニア • re:shine - リードエンジニア
3. Business introduction
4. re:shineとは? • 働き方の多様化支援プロジェクト ◦ 正社員でありながらフリーランスのような働き方を実現し、フリーランスでは積み上げづらい社会 的な信用や様々な報酬制度、税率の優遇された退職金制度など、一人ひとりに合った形の働き 方が出来る環境を目指す
5. サービスの特徴 • 契約形態選択型で、一人ひとりに合った働き方が可能 • コミュニケーションの確立されたチームでスムーズな業務 • プロジェクトで収入を得ながらスキルアップ • 各方面からの評価と個人のスキルから価値を可視化 • オンライン上で契約、請求書発行の自動化
6. チーム機能 機能紹介 プロジェクト機能
7. ユーザプロフィール 機能紹介 メッセージ機能
8. サービスロードマップ
9. @h-nago アプリケーションエンジニア @tsuyoshi-fukuzawa アプリケーションエンジニア @mcfish 事業責任者 @naomichi-y リードエンジニア メンバー紹介
10. クローズドβ（2018/10〜2019/4） オープンβ（2019/5〜2019/8） ポジション 人数 稼働の割合 リードエンジニア 1 0.4 フロントエンジニア 1 0.6 バックエンドエンジニア 1 0.7 デザイナー 1 0.2 ポジション 人数 稼働の割合 リードエンジニア 1 0.2 フロントエンジニア 1 0.6 バックエンドエンジニア 1 0.7 開発期間・編成チーム構成
11. System architecture
12. • インフラ ◦ AWS Well-Architected ◦ Infrastructure as Code ▪ Terraform ◦ Serverless Architecture ▪ AWS Lambda ▪ AWS Fargate アーキテクチャ設計 • アプリケーション ◦ SPA ◦ Twelve Factor App ◦ Microservice ▪ Open API + Trailblazer ◦ Identity as a Service ▪ AWS Cognito ▪ Firebase
13. 技術スタック
14. ネットワーク構成
15. AWS - サービス構成
16. • ほぼ全てのインフラ構成をコードベースで管理 • ソースコードをグループ会社に提供 ◦ 基盤を共通化することでインフラ構築のコストを削減、ノウハウを共有 Terraformによる構成管理
17. アプリケーション構成
18. • 2016年よりECSを運用 • ノウハウはQiitaにて公開中 ◦ ECS運用のノウハウ ◦ ECSにおけるログの扱い方 ◦ ECS Scheduled Tasksによるタスクの定期実行 ◦ ECSデプロイツールを公開しました ◦ Dockerコンテナデプロイサービスの比較 • デプロイツールをOSSとして公開 ◦ https://github.com/naomichi-y/ecs_deployer ◦ https://github.com/metaps/genova • 2018年よりFargateの運用を開始 ECSの導入
19. ECSクラスタ構成
20. マイクロサービス設計 - インフラ • APIのエンドポイント単位でスケール可能 • アプリケーションログはFargateクラスタに集約後、Fluentdで整形した上で Elasticsearchに流し込み、Kibanaでリアルタイムに可視化
21. マイクロサービス設計 - アプリケーション • ドメインを分析し、サービスの進化に柔軟に対応できる設計を目指す ◦ 機能単位に独立性の高いコンポーネントを実装 • フロントエンド、バックエンドの開発を分離 ◦ フロントエンド ▪ ユーザ認証: Firebase Authentication ▪ メッセージ機能: SendBird ▪ 契約締結: CloudSign ◦ バックエンド ▪ RailsはAPIモードで利用 ▪ API仕様はSwagger 3.0 ▪ 一部エンドポイントに GraphQLを検討中
22. Engineering management
23. • コードレビューの観点 ◦ コード品質を一定に保つ ◦ メンバーの育成 • テスト ◦ カバレッジ目標: 80% ◦ 実測値: 75.17% (2019年7月現在) • Slackインテグレーションの活用 ◦ 各種通知をSlackに集約 ▪ CI/CD、例外トラッキング、インフラ監視など ◦ オートデプロイ ▪ GitHubのpushを検知してECSにオートデプロイ ▪ Slackから手動デプロイすることも可能 開発体制
24. • 開発定例は週一 • デイリースクラムは行っていない ◦ Standup Aliceで進捗や問題点を報告 • 仕様書は書かない ◦ 機能要件はIssueベースでまとめる ▪ SlackよりIssueコメントのほうが活発 • 開発ガイドラインを策定、コードレビューを元にメンバー内で定期的な見直しを行 う • インフラ基盤は抽象化した設計とし、再利用しやすい構成を目指す • 公開できるライブラリはOSS化を目指す 開発方針
25. アカウント リポジトリ 概要 metaps genova AWS ECSデプロイマネージャ naomichi-y docker-fluent-logger RailsのログをFluentdが扱いやすい形式に変換 ecs-deployer AWS ECSデプロイツール mentions (fork) メンションをGitHubアカウントに変換して通知 aws-sns-slack-terraform (fork) AWS SNSメッセージをSlackに通知 fluent-plugin-grepcounter (fork) キーワードでログを集約 h-nago aws-reserve AWSリザーブドインスタンスの検出 reconnect_ar_rails AWS RDSがフェールオーバー時に再接続を行う 主なOSS活動 (2018-2019)
26. 今後の課題 • re:shine ◦ 事業的課題 ▪ ユーザーエンゲージメントの拡大施策 ▪ 利用者へのソースコード開示 ◦ 開発的課題 ▪ パフォーマンス改善 ▪ APMを用いたアプリケーション監視 ▪ 機械学習による異常検知の実装 ▪ SREチームの発足 • 全社横断的課題 ◦ ベースとなる開発言語やフレームワークの見直し ◦ 技術発信
27. 働くを、もっと楽しく簡単に