Slide 1

Slide 1 text

Naomichi Yamakita re:shine 開発基盤の概要

Slide 2

Slide 2 text

Naomichi Yamakita ● Metaps ESC - SRE ○ Metaps Engineer Steering Committee ● Metaps Alpha - インフラエンジニア ● pring - リードエンジニア ● re:shine - リードエンジニア

Slide 3

Slide 3 text

Business introduction

Slide 4

Slide 4 text

re:shineとは? ● 働き方の多様化支援プロジェクト ○ 正社員でありながらフリーランスのような働き方を実現し、フリーランスでは積み上げづらい社会 的な信用や様々な報酬制度、税率の優遇された退職金制度など、一人ひとりに合った形の働き 方が出来る環境を目指す

Slide 5

Slide 5 text

サービスの特徴 ● 契約形態選択型で、一人ひとりに合った働き方が可能 ● コミュニケーションの確立されたチームでスムーズな業務 ● プロジェクトで収入を得ながらスキルアップ ● 各方面からの評価と個人のスキルから価値を可視化 ● オンライン上で契約、請求書発行の自動化

Slide 6

Slide 6 text

チーム機能 機能紹介 プロジェクト機能

Slide 7

Slide 7 text

ユーザプロフィール 機能紹介 メッセージ機能

Slide 8

Slide 8 text

サービスロードマップ

Slide 9

Slide 9 text

@h-nago アプリケーションエンジニア @tsuyoshi-fukuzawa アプリケーションエンジニア @mcfish 事業責任者 @naomichi-y リードエンジニア メンバー紹介

Slide 10

Slide 10 text

クローズドβ(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 開発期間・編成チーム構成

Slide 11

Slide 11 text

System architecture

Slide 12

Slide 12 text

● インフラ ○ 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

Slide 13

Slide 13 text

技術スタック

Slide 14

Slide 14 text

ネットワーク構成

Slide 15

Slide 15 text

AWS - サービス構成

Slide 16

Slide 16 text

● ほぼ全てのインフラ構成をコードベースで管理 ● ソースコードをグループ会社に提供 ○ 基盤を共通化することでインフラ構築のコストを削減、ノウハウを共有 Terraformによる構成管理

Slide 17

Slide 17 text

アプリケーション構成

Slide 18

Slide 18 text

● 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の導入

Slide 19

Slide 19 text

ECSクラスタ構成

Slide 20

Slide 20 text

マイクロサービス設計 - インフラ ● APIのエンドポイント単位でスケール可能 ● アプリケーションログはFargateクラスタに集約後、Fluentdで整形した上で Elasticsearchに流し込み、Kibanaでリアルタイムに可視化

Slide 21

Slide 21 text

マイクロサービス設計 - アプリケーション ● ドメインを分析し、サービスの進化に柔軟に対応できる設計を目指す ○ 機能単位に独立性の高いコンポーネントを実装 ● フロントエンド、バックエンドの開発を分離 ○ フロントエンド ■ ユーザ認証: Firebase Authentication ■ メッセージ機能: SendBird ■ 契約締結: CloudSign ○ バックエンド ■ RailsはAPIモードで利用 ■ API仕様はSwagger 3.0 ■ 一部エンドポイントに GraphQLを検討中

Slide 22

Slide 22 text

Engineering management

Slide 23

Slide 23 text

● コードレビューの観点 ○ コード品質を一定に保つ ○ メンバーの育成 ● テスト ○ カバレッジ目標: 80% ○ 実測値: 75.17% (2019年7月現在) ● Slackインテグレーションの活用 ○ 各種通知をSlackに集約 ■ CI/CD、例外トラッキング、インフラ監視など ○ オートデプロイ ■ GitHubのpushを検知してECSにオートデプロイ ■ Slackから手動デプロイすることも可能 開発体制

Slide 24

Slide 24 text

● 開発定例は週一 ● デイリースクラムは行っていない ○ Standup Aliceで進捗や問題点を報告 ● 仕様書は書かない ○ 機能要件はIssueベースでまとめる ■ SlackよりIssueコメントのほうが活発 ● 開発ガイドラインを策定、コードレビューを元にメンバー内で定期的な見直しを行 う ● インフラ基盤は抽象化した設計とし、再利用しやすい構成を目指す ● 公開できるライブラリはOSS化を目指す 開発方針

Slide 25

Slide 25 text

アカウント リポジトリ 概要 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)

Slide 26

Slide 26 text

今後の課題 ● re:shine ○ 事業的課題 ■ ユーザーエンゲージメントの拡大施策 ■ 利用者へのソースコード開示 ○ 開発的課題 ■ パフォーマンス改善 ■ APMを用いたアプリケーション監視 ■ 機械学習による異常検知の実装 ■ SREチームの発足 ● 全社横断的課題 ○ ベースとなる開発言語やフレームワークの見直し ○ 技術発信

Slide 27

Slide 27 text

働くを、もっと楽しく簡単に