Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
re:shine 開発基盤の概要
Search
Naomichi Yamakita
July 14, 2019
0
12
re:shine 開発基盤の概要
Naomichi Yamakita
July 14, 2019
Tweet
Share
More Decks by Naomichi Yamakita
See All by Naomichi Yamakita
プロダクト横断で可視化する ダッシュボードの開発
naomichi
0
240
第一回ライブラリ開発について考える会
naomichi
0
72
Serverless Application Repositoryでトイルを削減する
naomichi
0
280
SRE的観点から日常を振り返る
naomichi
0
840
GMO Research Tech Conference 2023
naomichi
0
16
Deep dive into cloud design
naomichi
0
18
インフラを横断して可視化するダッシュボードの開発
naomichi
0
12
SREってどんな仕事___メタップスがSREチームを立ち上げたキッカケとこれから_.pptx.pdf
naomichi
0
10
SRE Innovation in Metaps
naomichi
0
270
Featured
See All Featured
Documentation Writing (for coders)
carmenintech
65
4.4k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
Testing 201, or: Great Expectations
jmmastey
38
7.1k
A Philosophy of Restraint
colly
203
16k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
27
2k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.2k
Designing the Hi-DPI Web
ddemaree
280
34k
Bash Introduction
62gerente
608
210k
Making Projects Easy
brettharned
115
5.9k
The Pragmatic Product Professional
lauravandoore
31
6.3k
Transcript
Naomichi Yamakita re:shine 開発基盤の概要
Naomichi Yamakita • Metaps ESC - SRE ◦ Metaps Engineer
Steering Committee • Metaps Alpha - インフラエンジニア • pring - リードエンジニア • re:shine - リードエンジニア
Business introduction
re:shineとは? • 働き方の多様化支援プロジェクト ◦ 正社員でありながらフリーランスのような働き方を実現し、フリーランスでは積み上げづらい社会 的な信用や様々な報酬制度、税率の優遇された退職金制度など、一人ひとりに合った形の働き 方が出来る環境を目指す
サービスの特徴 • 契約形態選択型で、一人ひとりに合った働き方が可能 • コミュニケーションの確立されたチームでスムーズな業務 • プロジェクトで収入を得ながらスキルアップ • 各方面からの評価と個人のスキルから価値を可視化 •
オンライン上で契約、請求書発行の自動化
チーム機能 機能紹介 プロジェクト機能
ユーザプロフィール 機能紹介 メッセージ機能
サービスロードマップ
@h-nago アプリケーションエンジニア @tsuyoshi-fukuzawa アプリケーションエンジニア @mcfish 事業責任者 @naomichi-y リードエンジニア メンバー紹介
クローズドβ(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 開発期間・編成チーム構成
System architecture
• インフラ ◦ 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
技術スタック
ネットワーク構成
AWS - サービス構成
• ほぼ全てのインフラ構成をコードベースで管理 • ソースコードをグループ会社に提供 ◦ 基盤を共通化することでインフラ構築のコストを削減、ノウハウを共有 Terraformによる構成管理
アプリケーション構成
• 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の導入
ECSクラスタ構成
マイクロサービス設計 - インフラ • APIのエンドポイント単位でスケール可能 • アプリケーションログはFargateクラスタに集約後、Fluentdで整形した上で Elasticsearchに流し込み、Kibanaでリアルタイムに可視化
マイクロサービス設計 - アプリケーション • ドメインを分析し、サービスの進化に柔軟に対応できる設計を目指す ◦ 機能単位に独立性の高いコンポーネントを実装 • フロントエンド、バックエンドの開発を分離 ◦
フロントエンド ▪ ユーザ認証: Firebase Authentication ▪ メッセージ機能: SendBird ▪ 契約締結: CloudSign ◦ バックエンド ▪ RailsはAPIモードで利用 ▪ API仕様はSwagger 3.0 ▪ 一部エンドポイントに GraphQLを検討中
Engineering management
• コードレビューの観点 ◦ コード品質を一定に保つ ◦ メンバーの育成 • テスト ◦ カバレッジ目標:
80% ◦ 実測値: 75.17% (2019年7月現在) • Slackインテグレーションの活用 ◦ 各種通知をSlackに集約 ▪ CI/CD、例外トラッキング、インフラ監視など ◦ オートデプロイ ▪ GitHubのpushを検知してECSにオートデプロイ ▪ Slackから手動デプロイすることも可能 開発体制
• 開発定例は週一 • デイリースクラムは行っていない ◦ Standup Aliceで進捗や問題点を報告 • 仕様書は書かない ◦
機能要件はIssueベースでまとめる ▪ SlackよりIssueコメントのほうが活発 • 開発ガイドラインを策定、コードレビューを元にメンバー内で定期的な見直しを行 う • インフラ基盤は抽象化した設計とし、再利用しやすい構成を目指す • 公開できるライブラリはOSS化を目指す 開発方針
アカウント リポジトリ 概要 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)
今後の課題 • re:shine ◦ 事業的課題 ▪ ユーザーエンゲージメントの拡大施策 ▪ 利用者へのソースコード開示 ◦
開発的課題 ▪ パフォーマンス改善 ▪ APMを用いたアプリケーション監視 ▪ 機械学習による異常検知の実装 ▪ SREチームの発足 • 全社横断的課題 ◦ ベースとなる開発言語やフレームワークの見直し ◦ 技術発信
働くを、もっと楽しく簡単に