インフラチームと協力し、運用の手間が少ないシステムを実現
「Googlebotのためにチューニングするということを繰り返していくと、それに要する時間がもったいない。そのための対策を練るためにインフラチームと対応を協議することにした」と古畑氏は語る。その結果、従来の構成にAWSのAutoScale機能を導入し、最大8台まで自動でオートスケールする仕組みにしたのである。この仕組みにより、「今後Googlebotが来ても、自動でスケールされるので、その手間から解放されるようになった」と古畑氏は満足そうに語る。
開発スピードの向上にも取り組んだが、「いろいろ解決すべき課題があった」と古畑氏。その一つが「秘伝のタレ化」、つまり担当者しかわからない属人的なセットアップ手順が存在していたことだ。同社では普段の開発はデスクトップPCで開発しており、その環境はWindows＋XAMPPを採用している。海外チームは人数も少ないため、結合試験用のサーバは1台のみで、それをVirtualHostで切り分けて複数の機能のテストをしたりするため、VirtualHost職人的な人が存在していたというのだ。開発環境の理解に時間がかかる上、「●●さんに聞けばわかる」という状態を放置したままでは、そこがボトルネックになってしまう。
そこで「新人が入ってきてもすぐに開発に着手できるよう、開発環境をもっとシンプルにすることにした」と古畑氏。ミドルウェアやアプリケーションのセットアッププロセスをDockerに格納したのだ。DockerfileはGitで管理。Gitを選択したのは「ブラックボックスになっていると秘伝のタレ化しやすい。環境構築に関わるものを全てGitで管理し、チームメンバーに対してオープンな状況にしたかった」と語る。そして各エンジニアのローカルマシンには、Docker Machineを導入し、「Linux上で開発しているような環境を実現した」と言う。さらに結合試験環境にはAmazon ECS、DockerリポジトリにはAmazon ECRを採用。これによりできあがったのが、下図のような環境である。「今はまだECSの部分はまだ本番運用には至っていないが、それを早期に実現する予定。さらに今後は自動テストが完了した後、本番環境にそのまま移行できるような環境を構築していきたい」と意気込む。
このような仕組みを構築するに至り、「苦労したこともある」と古畑氏。その一つがDockerに対する知識があまりなかったこと。実は古畑氏は海外チームに異動するまで、SEOの担当だったという。そのため、Docker Swarm、ECS、ECRなどの知識に乏しく、勉強に苦労したというのだ。
もう一つがコミュニケーションである。Dockerに詳しいのはインフラチームのメンバーだが、古畑氏の知識不足により的確な質問ができなかったりしたそうだ。どんなことをするにしても「コミュニケーションは大事」と古畑氏は強調する。古畑氏はコミュニケーションを取る際は、歩み寄り笑顔で直接話しかけることを心がけたという。「そうすることで、互いの理解を深めることができた」と言い切る。
また海外チームならではの取り組みはほかにもある。例えば、国内サイトでは定例リリース日を設けているのだが、海外ECサイトでは設けていない。国内サイトで定例リリース日を設けている理由は、リリースタイミングを集中させ、何か不具合があった場合のお客さまへの影響を局所化させたり、開発にリズムを持たせたりすることができるという技術的およびビジネス的なメリットがあるからだ。一方で、リリース可能な状態の機能があるのにも関わらず、リリース日までその機能をリリースできないので、その機能が生み出すであろう利益の機会を損失してしまうデメリットがある。海外チームのミッションは売り上げを上げること。そこで古畑氏は、そのデメリットを排除するため、リリース可能状態になった機能はその日のうちにリリースし、利益を受け取れるまでの期間を短縮しているという。
モノタロウでは、どんな技術に取り組んでいるかなど外部に発信する機会「MonotaRO TechTalk」というイベントも設けている。最後に古畑氏は「エンジニアも募集しているので、興味のある人はぜひ」と呼びかけ、セッションを終えた。
お問い合わせ
株式会社MonotaRO
