metapsでエンジニアをしている山浦です。
今回は、metapsの数ある事業の中でも比較的新しい事業の１つ
「re:shine」の開発基盤について勉強会が開かれたのでその実況をしていきます。
re:shineについて、詳しく知りたい方はこちら
metapsは複数の事業がある上に、子会社化していたりするので
各社のエンジニアが分散しがちなので
このような全社横断的にエンジニアが集まる勉強会があると、
何かと助かりますね！
勉強会に向けて続々と、エンジニアの方々が集まってきました！
参加者34名が揃ったところで、いよいよ開催です。
今回のre:shineの開発基盤の話しをしていただくのは”山北 尚道”さん。
Metaps本社のESC(Engineer Steering Commitiee)で
全社横断SRE(Site Reliability Engineering)的な動きをしつつ
Metaps-Alphaでインフラエンジニア 兼
pringのリードエンジニア 兼
新規事業であるre:shineの開発責任者…
この記事を書いている私は、
入社間もない、新米エンジニアですが、
これだけはわかります。
間違いなく、
つよつよエンジニアです。
ますます、話を聞くのが楽しみになってきましたね！
※ESC(Engineer Steering Commitiee) についてはまたどこかで紹介します。
※SRE(Site Reliability Engineering): Webサイトやサービスの信頼性向上に向けた取り組みを行い、価値の向上を進める役割。
では、本題へ。
re:shineの技術構成は？
技術スタックは多め
使用している技術スタックは、
一覧にするとこのような感じ。
Codetreeは、GithubのIssue管理ツール、
デザイン周りには、ZeplinやSketchを
DB設計には、MySQLWorkbenchやdrow.io
ドキュメント管理として、DocBase
フロントはVue.js
バックエンドは基本的にはRailsがメイン
サービスの仕様上、契約書や請求書等を扱うので、CloudSign (API連携)
メッセージ機能のSendBird
CI/CDツールとして、CircleCI、Trivy、genova
Datadogはインフラ監視ツール
ログの収集・解析ツールとして、FluentdやElasticsearchを使用し
その基盤として、ログの集積・解析基盤としてFluentdやElasticsearch、視覚化にはKibanaを使用しているとのこと。
（じ、情報量が多すぎて、ついていけませんっ！（汗））
インフラ構成はTeraformを使い、共通化を
多くのサービスを使っていますが、
インフラ構成に関しては、Terraformでコード管理されており、
各社のインフラ基盤を共通化することで
コスト削減やノウハウの共有をスムーズに行っているようです
ECSは導入して３年目！デプロイツールもOSSで公開中！
ECSは初期の2016年から本番環境で運用しており
Dockerベースのアプリケーションを本番環境で動かすことは早い段階から行なっていました。
そのノウハウを活かし、
ECSのデプロイツールを開発し、OSSとして公開しています。
https://github.com/metaps/genova
また、Fargateの運用を
ログ基盤などから少しずつ始めているとのこと。
※ Fargate: サーバーやクラスターの管理が必要ない、コンテナを実行するためのECSに対応したコンピューティングエンジン
ECSのクラスタは、汎用的に使い回せる構成に！
ECSのアプリケーションクラスタには、フロントとバックエンドのコンテナがあり、
さらにその２つをDatadog agentが監視。
さらに、そこからCloudMapを使い、Fargate経由で
各ログを、fluentdに集約、また加工した上で
Elasticsearch ServiceやS3に保存しています。
各コンテナからのログを綺麗に整理して一元化するこの構成は、
汎用性も高く、使い回せる構成となってますね！
APIベースで開発することで、機能単位にスケールが可能に
また、基本的に全てのアプリケーションを
APIベースで開発しておりエンドポイント単位でスケールが可能。
メッセージ機能などの瞬間的に高負荷になりやすいエンドポイントを
限定的にスケール可能です。
これにより、メディアで取り上げられた時に発生する
突発的なトラフィックの増加にも耐えられる仕様になっています。
※Fluentd:オープンソースのログ収集管理ツール。ログのI/Oを制御します。
※Elasticsearch:Elastic社が開発している、スケーラビリティに優れた全文検索エンジン。
※Kibana:Elastic社が開発しているビジュアライゼーションツール。Elasticserachに入っているデータを様々な形式で視覚化することができる。
metapsの開発環境とマネジメントについて
さて、ここからはre:shineの開発環境ではなく、
metapsのエンジニアマネジメントや開発環境についてご紹介していきます。
安心してください。コードレビューで強烈なマサカリは飛んできません 笑
開発体制として、
コードレビューや、カバレッジ目標を80%に設定したテストなどにも力を入れています。
metapsでは、コードレビューをissueベースで行なっています。
また、コード品質を一定に保つために開発ガイドラインも策定しています。
レビューされるポイントが、ある程度決まっているので、強烈なマサカリが、
飛んでくることはまずありません。
心理的に安心ですね。笑
各種通知はSlackに集約しており、GitHub上のメンションをSlackのmentionにマッピングするボットなどの工夫で「気づきづらい」環境なども改善しており、
レビューや開発体制としては、やりやすい環境です！
（AWSへのオートデプロイもSlackで通知を受け取れるようにしたり、
Slackからデプロイも可能にしたりしている点も面白いですね）
開発方針は、NO朝会、NO仕様書
よく行いがちなデイリースクラムや朝会はありません。
機能要件はIssueベースでまとめています。
気づけば、Slackで話すよりIssueのコメントの方が活発なことも 笑
公開できそうなライブラリはOSS化を目指したりと積極的に発信していっています。
（昨年のOSS活動は、8個。今年は、それ以上…?!）
まとめ
さて、一通り話してきましたが、
少しでもmetapsの開発環境や、技術スタックが伝わったでしょうか？！
比較的新しい事業サービスの、技術紹介だったこともあり
- 非常に多くの技術やアプリケーション
- ECSやDocker周りのノウハウの蓄積
- 積極的なOSS活動
など、metapsならではの魅力や、社内の雰囲気を少しでも
感じていただけると嬉しいです。
metapsでは、
積極的に技術発信やOSS活動をしたいという人や、
◯◯のことなら、私に聞け！というベテランの方から少しでも成長したい！
という若手まで、幅広く採用活動を行なっております。
ご興味のある方は、是非ご連絡ください。
