複雑なサービスの 複雑なサービスの 開発環境 開発環境 メドピア株式会社 侘美 怜

自己紹介 自己紹介 侘美 怜 (たくみ さとし) Twitter: GitHub: Qiita: 2019年2月にメドピアへ入社 SRE 兼 サーバーサイドエンジニア 趣味は猫を愛でること reirei_As reireias reireias

本日の話 本日の話 ローカルの開発環境について ローカルの開発環境について

サービスが成長する過程でアーキテクチャは サービスが成長する過程でアーキテクチャは どんどん複雑になっていく どんどん複雑になっていく PaaS/SaaSの活用 例：Elasticsearch、S3、Lambda 歴史的経緯による複雑化 技術的負債 マイクロサービス化等のアーキテクチャ変更

メドピアも年々複雑なアーキテクチャに... メドピアも年々複雑なアーキテクチャに... ここでやばいアーキテクチャを見せる

複雑化していく過程でローカルの開発環境も複雑に 複雑化していく過程でローカルの開発環境も複雑に README.mdがツギハギだらけに 全体を知る人が少なくなる そして、次第にメンテされなくなっていく... 開発効率が下がっていく... という光景を幾度となく目にしてきた

開発環境は大事 開発環境は大事 日々利用するので生産性に直結 CIにも共通する

これまで培ってきた これまで培ってきた ノウハウや課題を共有します ノウハウや課題を共有します

3つの課題 3つの課題 1. PaaS/SaaSをどうする問題 2. コンテナとローカルの連携どうする問題 3. Docker for Mac遅い問題

1. PaaS/SaaSをどうする問題 1. PaaS/SaaSをどうする問題 スピーディーな開発にはPaaS/SaaSの利用は不可欠 例: S3、Lambda、Elasticsearch 課題: これらを開発環境ではどうする？

対策1: 同じものをローカルで動かす 対策1: 同じものをローカルで動かす ローカルでも動作可能なOSSの場合はこれ 例：MySQL、Elasticsearch、Redis 公式のコンテナイメージを利用するのが良い

対策2: 代替OSSをローカルで動かす 対策2: 代替OSSをローカルで動かす AWS固有のものとかは代替となるOSSがあったりする 例：S3 -> minio、Lambda/SQS/SNS等 -> LocalStack Mailはmailcatcherが最近は人気

対策3: 直接PaaS/SaaSに接続 対策3: 直接PaaS/SaaSに接続 本番と同一のサービスを利用できるという点では良い 開発者が多いと辛くなってくる コストもかかる 　 対策4: 実装で切り替える 対策4: 実装で切り替える できる限り採用したくない 例：本番やテスト環境ではS3に接続するが、ローカル ではファイルシステムを使う ローカルやCIでは実施されないコードが出てくる

2. コンテナとローカルの連携どうする問題 2. コンテナとローカルの連携どうする問題 コンテナ内で動作させながら開発するケース 依存が複雑で構築が手間 開発環境の統一 課題：どうやってコーディングするか？

対策1. Docker Volumeを使う 対策1. Docker Volumeを使う DockerのVolumeでローカルのコードをマウント 好きなエディタで編集 lintやテストのエディタ連携は少し工夫する必要あり 同一バージョンをローカルにも入れる 実行パスを修正してコンテナ内のものを実行する

対策2. VS Code Remote Development機能を使う 対策2. VS Code Remote Development機能を使う コンテナ内でVS Code Serverが起動する仕組み 既存のdocker-compose.ymlを流用して設定が可能 まだ試せていないが、かなり良さそう

対策2. VS Code Remote Development機能を使う 対策2. VS Code Remote Development機能を使う デメリット：私はVimmerである

3. Docker for Mac遅い問題 3. Docker for Mac遅い問題 課題：Docker for Macとホスト間のファイル同期が遅い 理由：MacのDockerはネイティブでない(間にxhyve) マウントなので、ファイルへのアクセス全般が遅い デバッグやテストのパフォーマンスが低下

対策1. Docker Volumeのオプションを利用する 対策1. Docker Volumeのオプションを利用する 以下のオプションを利用する consistent デフォルト cached ホストからコンテナへの更新の遅延を許可する コンテナ内のreadの高速化 delegated コンテナからホストへの更新の遅延を許可する コンテナ内のread/writeの高速化 例： が 486s -> 49s まで高速化 https://docs.docker.com/docker-for-mac/osxfs-caching/

対策1. Docker Volumeのオプションを利用する 対策1. Docker Volumeのオプションを利用する での設定例 version: '3' services: app: image: alpine:latest volumes: # :: 形式 指定 - /path/to/app:/app:delegated

対策2. docker-syncによる同期の高速化 対策2. docker-syncによる同期の高速化 を利用する オプションよりも約2倍程度速い 例：メドピアのとあるページの表示速度 オプション => 2.4秒 => 1.0秒 docker-sync

before after 対策2. docker-syncによる同期の高速化 対策2. docker-syncによる同期の高速化 # docker-compose.yml services: app: volumes: - /path/to/app:/app # docker-compose.yml services: app: volumes: - sync-volume:/app volumes: sync-volume: external: true # docker-sync.yml version: '2' syncs: sync-volume: src: '/path/to/app'

参考：docker-syncの仕組み 参考：docker-syncの仕組み https://docker-sync.readthedocs.io/en/latest/advanced/sync-strategies.html

対策3. 開発マシンをLinuxにする 対策3. 開発マシンをLinuxにする プロダクトはAmazon LinuxやAlpineで動いている プロダクトへのコンテナの導入も活発になってきている Linuxが最も開発機に適しているのは自明で Linuxが最も開発機に適しているのは自明で ある！ ある！ まあ、現実的には情シスとか社内ルールによって無理だっ たり...

まとめ まとめ 開発環境は大事、メンテしよう Linuxで開発したい Dockerを上手く活用しよう docker-composeによる構築の簡易化 CI環境への流用/共通化が簡単 Linuxで開発したい

ご清聴ありがとうございました ご清聴ありがとうございました