2018.2.20(火)渋谷TechPlayで開催された「事業の多角化を支えたランサーズ的SRE術」に参加してきた。
以下はその時のメモ。
CTO横井さん
- Lancersの概要(最近資金調達したよ、160人くらいいるよ、働き方の改革を進めてるよ)
- 2年くらい前から新しいサービス提供をはじめた。quantというサービス、デジタルマーケティング、Adテクノロジー
- pook C to C サービス。家事代行とか。オフラインのサービス。
- 地方創生事業(奄美大島とか)、仕事がないのでクラウドソーシングで仕事創出。→エンジニアのさすらいワークとしても実施している。リモートワークの採用。
- エンジニアは30名程度。
- SREは4名。
- SREチームにしたから何かが変わったことはない。
平塚さん
- ECSの話
- 去年の10月まではSREは2人
- 今は4人
- 大きく4つのサービス
- Lancers/Quant,TOP/Pook,Sub 20Services
- 複数のプログラム(CakePHP,Go,Rails)
- Terraform,ANSIBLEで管理。
- 開発環境はDocker,アプリケーションエンジニアもDocker。
- ECSだったらDockerそのままもっていけるのでは?
- 環境はTerraformとECS-CLI. ECS-CLIはECSのみ管理。VPSとかSGとかは Terraform.
- なぜECS?→ プロトタイプ環境構築のスピード感。
- 構成管理が実態と剥離してきた
- OSSのバージョンアップ→ ゴミファイルが残ってしまう->きれいにした状態で再作成しなおせる
- 手作業をやめる
- k8sを選択していない理由->AWSのオーケストレーションはECS一択なのでECS.
- The Twelve-Factor App を参考に(https://12factor.net/ja/)
- サービス
- ユーザー -> ALB -> Nginx -> ALB -> Admin,API,Job,Batch -> Redis,RDS
ユーザー -> CloudFront -> S3
- ユーザー -> ALB -> Nginx -> ALB -> Admin,API,Job,Batch -> Redis,RDS
- ポートマッピング(動的ポートマッピング)
- Dockerfileはシンプルにしている
- リリースツールはECS-CLI。ECSでTask Defitnition,Service Definitionで定義した情報をもとに構成する。
- Pook は Rails.Puma.
- リリース: deployツールがあるので、ECSへデプロイできるようになっている内製のWebUIがある。
- ログ: CloudWatch -> ElasticSearch
-> Lamda -> S3 - pip install awslogs
- ECRはhub.docker.comみたいなイメージが保存できる
- ECRはライフタイムサイクル設定できる
ameshoさん
- Digdagの話
- Quant -> Rails,redshift,aurora
- バッチ運用がどうかわったのか。digdagの運用。起きた問題など。
- 導入前まではcron。
- どこで、いつ実行されているかがわかりにくい
- 依存がわかりにくい
- Digdagを導入したことで、管理画面で管理できるようになってわかりやすくなった
- 設定がyamlで順番に実行されているのでアラートがあがった際につきとめやすくなった
- 管理画面にプログレスバーがあって処理時間を把握しやすくなった
- 上司や同僚に対して認識共有がしやすくなった
- エンジニアを介すことなくバッチ実行をしやすくなったメンバーがいる
- Digdagを中心に開発を進めているのに近い
- Digdag用リポジトリにPRしてマージして、Digdagサーバーでcheckoutしている。デプロイは手動。
- 不足している機能はembulkを利用している
- Digdagの注意点としてDocument化されていないところとかがある。
- Digdag起動したら一緒に謎のAPIサーバーが起動していた -> API経由でアクセスできるようになってた
- Document上は使えそうに見えたけどソースコード上に未実装だよコメントがあったりする。OSSあるある..
- バッチの実行についてチームで共有されたのがとても良かった
- Digdagを間口にして、データ転送、クエリの定期実行を追加しやすくなった(エンジニアが介さず)
- 一年間使った感想としては使ったほうが良い
金澤さん
- Windowsのパッケージ開発をしていた。C++,Java,SNS開発(PHP)&インフラ(オンプレ)
- 構成:APIはPythonで作ってる。PHPとつなげるため。
- インフラエンジニア2人+インターン+新卒
- OSSに貢献する
- インフラチームをボトルネックにしない->差し込みは即対応
- 定型作業の移譲->依頼元がインフラに依頼しなくても良い環境にしていくことを重視している
- MySQLのFULLTEXTインデックスが度々壊れてサービスが全停止。MySQL5.1でinnodbだった。
- RDSのMultiAZ,MySQL5.6。FULLINDEXインデックスが利用できるように。
- CakePHPで VIEWCACHEをNFSにおいてあった
- memcachedに移行,NFS(SPoF)を廃止
- AWSをAZを分割したのでAZ障害に対応できるような環境にした
- RDS -> Aurora
- サーバーレスポンス -> DBがほとんど原因
- ブランザレスポンス -> CDNなどで対応
- メモリとCPU比率が固定 -> ApacheでMacperchildを3000から50にしてメモリが太らないように
- EC2内はhttpにすることでメモリ使用量が半減
- Chatworkにスロークエリを通知するようになっている
- 昔インデックスが酷かった
- MySQLは1テーブルに1インデックスしか使えない
- 不適切なインデックスを掃除することから始めた
- インデックスを削除すれば改善するがインデックスをつけた理由があるので、インデックスを外すと別のクエリが遅くなる場合がある
- ランサーズの各画面で流れるクエリログをスクリプト化
- カーディナリティが低いの見直し
- FORECE INDEXの利用 -> 経過観察
- 全文検索をCloudSearch
- ANSIBLE,Terrform
- エンジニア以外の人がSQLを叩くことがある
- SQLクライアントにSSHトンネルでつないでる
- Athenaに移行しつつある
- 開発環境はDocker
- ECRにイメージをあげて、開発はそのイメージをプルすれば使えるようにしている
- 不要なサービスや不要なコード、機能の削除業務を進めている
わかりやすいECS,コンテナ導入の話だった。
ツール作成など積極的にされているようだったので、その辺チームで活発なんだろうなぁという印象をうけた。
Terraformで導入しなかった点があるようだったけど、時間の都合上本発表には含まれていなかったので気になった。
今後EKSは利用検討しているのか聞けばよかったかも。
自身の担当サービスで唯一(?)ECS導入したようだったので、良い意味で社内でも影響の大きなリリースだっただろうなぁと思った。
digdag導入の話で印象的だったのは、digdagを中心に運用をすすめるようになった所があるということだった。
redashとかみたいに、今までは専用のアプリケーションがないと駄目だったところをOSSのツールでいい感じに業務ツールとして導入できるというのが分かった。
多分この話を聞いてdigdag導入したいなぁと思った人は多いハズ。
最後にランサーズのインフラの歴史とこれからというような感じの話。
インフラエンジニアがいないところから、ミドルウェアのバージョンやAWSのサービスキャッチアップだけじゃなくて、アプリケーション側の視点で改善を進めている所がとても印象的だった。
元々Windowsのアプリケーションを作っていて、大学ではネットワークをしていて、仕事でインフラみていて今はAWSを見ているのでまさに下から上までできる方なのだなぁと感じた。
そういった所で、アプリケーションエンジニアとインフラをバランス良く見ていて、常に新しいところを目指していっていそうだというところがとても素晴らしかった。
先日、イベントのことを知って、近くだし行ってみようと思って勢いで参加したけれどとても学びになった。