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チームの発足 ● 全社横断的課題 ○ ベースとなる開発言語やフレームワークの見直し ○ 技術発信 

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