技術コーチなど外部の有識者に依頼するときの失敗パターンと成功のポイント

これはVOYAGE GROUP Techlog Advent Calendar 2020の1日目です。

adventar.org

昨日のイベントで「開発企業が技術コーチを依頼するとき、どんな人に依頼すれば良いのか、人選でどのような点に気をつければ良いでしょうか?」という質問があり、イベント中に口頭で回答し、その後下記をツイートしました。

思ったよりいいねをもらったので成功のポイントについても書いておきます。

経験

VOYAGE GROUPでは2014年から Takuto Wada (@t_wada) | Twitter さんに技術コーチをしてもらっています。以前は週に2日、今は週に1日です。 また、 そーだい@初代ALF (@soudai1025) | Twitter さんが独立してからは、週に1日チームメンバーの一員としてガッツリ入ってもらってます。

その他にも何人か外部の有識者に依頼してきました。

失敗パターン

自分たちの経験や他の会社の話を聞くと下記のような失敗パターンがあると思います。

  • 解決する課題が定まっていない
  • 解決したい課題とコーチの得意分野がフィットしていない
  • 業務開始時点でやってもらうことが決まってない

「えっ、外部に依頼するのにそんなことある?」と思うかもしれませんが、うまくいかなかったときの話を聞くと意外と上記のようなことがありました。

成功のポイント

とはいえ、今まで一緒に仕事したことない場合はフィットするかを判断するのは難しいことです。下記のように小さく試していくようにするとよさそうと思います。

  • 3ヶ月/半年のゴールを設定する
  • 長期契約の前に1−2日のお試し日を設ける
  • 稼働日の終わりに夕会などで次回までの宿題を決める
  • 前日までに稼働日のタスクを決めておく

おまけ

「できるエンジニアだと知人から聞いたので、とりあえず3ヶ月来てもらうことにした。詳細は来てもらってから現場で考えてね。あとよろしく」みたいなのが失敗あるあるな気がします...w

「3つの立場からエコシステムの変化を把握する」Tech x Marketing meetup #6 iOS x AD レポート

こんにちは。技術広報の丹野 (@tan2) です。

今回は先日行われた「Tech x Marketing meetup #6 iOS x AD」 #TechMar をレポートをしていきたいと思います。 冒頭からいきなり感想をいってしまうと「最新のiOS上での広告エコシステムの変化を3つの立場から把握できた」とても良いイベントでした。

Tech x Marketing meetup とは

日本においてDXが不可欠と言われているなか、多くの企業がデジタルマーケティング領域においてテクノロジーによる進化に取り組みんでいます。Tech x Marketing meetupは、それらを実際に支えている技術/エンジニアリングや組織、文化について共有しつつ、盛り上げていくためのイベントとして、電通デジタルセプテーニ・オリジナルCCI、そしてVOYAGE GROUPの4社が共同主催する形で立ち上がりました。

今回のテーマは「iOS x AD」

第六回を数える今回は「iOS x AD」と題して、iOS14のリリースを期に大きく移り変わる広告配信やプライバシーへの取り組み/仕組みの変化に関して、これまでの経緯や各社の対応、今後の展望などについてセッションやパネルディスカッションが行われました。 VOYAGE GROUPからは、fluct アリムラ、Zucks 南大津が出演し、それぞれ「iOS 14で起きる広告配信/計測の変化に備える」「SKAdNetworkの解説と対応」などについてお話してきました。

セッションとパネルディスカッション

f:id:tan2jpn:20201125182212p:plainf:id:tan2jpn:20201125182021p:plain

セッション1 「iOS 14で起きる広告配信/計測の変化に備える」

1つ目のセッションはメディア/アプリ事業者側に寄り添う立場であるVOYAGE GROUP/fluctのアリムラから。

2020年6月にWWDC 2020で発表されたiOS14からIDFA(広告識別子)の取得方式がオプトイン方式になるという発表がされました。2020年におけるiOS上での広告配信/計測のエコシステムはこのIDFAが広く使われており、関係者の中でも大きな話題となりました。

2020年9月には、iOS14でのIDFAのオプトイン方式化は2021年に延期されましたが、引き続き動向が注目されています。

このセッションでは冒頭に、そもそもIDFAとはどういったものか、広告配信/計測に実際にどのように使われ、どのような特徴があるのかなど、広告配信に詳しくない方でもわかりやすく解説されていました。

その上で、2021年以降どのようになっていくのか、IDFAに変わる手法、計測ベンダーの動向、2021年までにiOSアプリの開発者にするべきこと、などの説明がありました。iOSアプリの開発に直接的に関わる人も、そうでない人も、iOSやプライバシーにまつわる大きな変化として是非知っておきたい内容でしたね。

セッション2 「SKAdNetworkの解説と対応」

続いて、2つ目のセッションは主に広告主側に寄り添うVOYAGE GROUP/Zucks 南大津から。

IDFAを必要とせず広告配信の効果を計測する「SKAdNetwork」という仕組みについて詳しい解説がありました。

SKAdNetworkは、Appleが提供するiOSアプリ上でアプリの広告を配信するときのみに利用可能な仕組みで、プライバシーに配慮した計測が可能なものとのこと。元々iOS11.2から利用可能だった仕組みでしたが、iOS14になりバージョン2.0にアップデートされ計測可能な項目が増えたそうです。

このセッションでは、SKAdNetworkの詳しい解説、計測の流れや計測できる内容、広告配信事業者・広告掲載アプリ・広告主アプリの対応内容について説明されていました。現時点での各社の対応状況などの最新情報や今後の展望もあり、広告を扱うアプリ開発者なら必修では?とも思える内容でした。

特に最新情報や今後の展望については、まだ動向が定まっていない中では貴重な情報でしたね。

セッション3 「iOS14 GANMA!の対応」

3つ目のセッションは、マンガアプリのGANMA!を運営するセプテーニ・オリジナル 佐野さんから。

GANMA!はプレミアム会員からの課金収益に加えて、無料会員からの広告収益があるそうです。 セッションでは、GANMA!がコンシューマ向けサービスということもあり、WWDC Build trust through better privacyで発表されたプライバシーに関する4つの柱の説明から始まりました。

セッション1でも解説のあったIDFAの取得がオプトイン方式になることで、いかにしてUXを損なわずに、かつ必要性を理解してもらいつつユーザから許諾をいただくかか、アプリから見た「SKAdNetwork」、既存のADNetworkへの影響、MMP(Mobile Measurement Partner)いわゆる計測への影響、それらとAppleのガイドラインを踏まえたGANMA!としての動き、様々なケースを想定したA/Bテストのお話など、アプリ運営者ならでは観点やケーススタディはとても具体的で興味深いお話でした。

「iOS x AD」パネルディスカッション

モデレータとして電通デジタルのリチャード伊真岡さん、パネラーとしてVOYAGE GROUP/fluctからアリムラさん、セプテーニオリジナルから佐野さんが参加してざっくばらんに質問に答えていきました。その一部を実況ツイートを引用して雰囲気をお伝えしたいと思います。

他にも、イベント限定のここだけの話的なお話もあり、とても貴重な時間でした! f:id:tan2jpn:20201126003428p:plain

#TechMarツイートまとめ

ハッシュタグ #TechMar に寄せられたセッションや質疑応答の内容に合わせたツイートをこちらにまとめています。 togetter.com

スマートフォン上の広告エコシステムとその変化

昨今、私たちは仕事でもプライベートでも日々スマートフォンでアプリやブラウザを高頻度で利用するようになっています。 そのため人々に自社製品を知ってもらいたいと考える多くの企業(広告主)にとって、スマートフォン上の広告は重要チャネルとなってきています。 また広告収益がアプリやサービス提供者の大事な収益源の一つになっていることで、私たちは一部のアプリやサービスを無料で利用することができています。

このように広告のエコシステムには様々な関係者が関わっていますし、iOSを提供するAppleなどのプラットフォーマーの動向に対してどう向き合っていくのかも重要です。

今回はそのような広告エコシステムに関わる3つの立場(アプリ提供者側に寄り添うfluct社、主に広告主側に寄り添うZucks社、アプリ運営者として広告掲載&広告主のセプテーニ・オリジナル社)からのセッションとパネルディスカッションとなっており、立体的にこのエコシステムに起こりつつある最新の変化が把握できて、とても面白い回だったのではないでしょうか。

もっと盛り上げていくぞ!

Tech x Marketing meetupはこれまでも「アドテク」「Privacy Sandbox」「データサイエンス」「データエンジニアリング」「SRE」などテーマで定期的にイベントを行っています。まだ2020年に立ち上がったばかりですが、技術の力でマーケティングをより良くしていくべく、より一層盛り上げていきたいと考えています。また、マーケティング界隈のエンジニアが集まる場がまだまだ少ないと感じているので、もっとワイワイできる場を作っていきたいですね。

以下のconnpassやTwitterでイベントや技術/マーケティングに関する情報などを発信しているので、興味を持った方は是非フォローしていただけると嬉しいです。

techxmarketing.connpass.com

twitter.com

[PR] VOYAGE GROUPでは仲間を積極大募集中です

そしてそして、今回のイベントに出演したアリムラ/南大津がそれぞれ所属するfluct/Zucksでは、この変化の激しい市場や事業と向き合いエンジニアリングしながら、ワイワイ共に成長していける仲間を積極大募集中です。

fluct

Zucks

Ask the Engineers in VOYAGE

また、もうちょっと話を聞いてみたい。VOYAGE GROUPでの働き方・文化など、実際に応募する前に聞いてみたいことなどについて、ざっくばらんにお話し聞いてみたい方はカジュアルな面談も調整しています。すぐに選考を希望する方でなくとも問題ありませんし、情報交換からという方も歓迎なので、お気軽に応募いただけると嬉しいです。 - hrmos.co

そーだいなるVOYAGE GROUPの裏側 #SPZ 事業の成長を止めない手段としてのシステム刷新

 今日も@soudai1025 こと id:Soudai がお届けします。

 そーだいなるVOYAGE GROUPの裏側は #voyagebook のイベントとして、各事業部のエンジニアにパネルディスカッション形式で話をしていく企画です。 第六回の今回は「事業の成長を止めない手段としてのシステム刷新」と題してサポーターズ(以下 SPZ )のみんなとディスカッションしてきました!

f:id:voyagegroup_tech:20201120140132j:plain

 資料の中にSPZの紹介やパネラーの自己紹介もあります。

 質疑応答の内容に合わせたツイートなどのまとめはこちら。

togetter.com

 実際のパネルディスカッションの様子は上記の動画をどうぞ。

今回はビジネスサイド代表で参加したpiroさんから、素晴らしい発言が連発でしたね! 特に私はこのセリフには感動しました。

 チームの信頼関係が要所要所で感じられるいい話でした。 ぜひみんなも見てみてください。

感想

 今回はSPZのお話でした。 フルリプレイス、完遂するのはとても難しく、また完遂しても満足できる結果にならないことは珍しくありません。 それほどフルリプレイスは難易度高く、勇気が必要な決断なわけですが、サポーターズも例に漏れず、一度失敗しています。

 その経験を活かした二度目のチャレンジがなぜうまく行ったのか。その理由が余すことなく見えた回だったなと思います。

 よく言われるフルリプレイスのタイミングで捨てる、だけではなくて、チームの信頼関係や文化も合わせて一緒にリビルドしたのは素晴らしいですし、大事な知見ですね。

 そして会のあとにパネラーの @nekoya さんが大事なことをツイートしてたのでそちらも紹介します。

 常に他者に対するリスペクト、サービスに対するパッション、そしてメンバーに対するトラストを感じる、サポーターズのみんなと一緒に働いてみたいなって思ってしまうようなウィットに富んだ回でした。 ぜひみなさんもご覧ください。

次回予告

 ついに次回のそーだいなるVOYAGE GROUPの裏側で 最終回 です! 総集編と題して、本の中でのインタビュワーである @t_wada さんとVOYAGE GROUPのCTOである @makoga さんと3人で各章を振り返っていきます。

 そして最終回は夜から開始で特大版、質問も大募集しますので、みんなも過去の動画を見て、復習しましょう!!!

f:id:Soudai:20201120114544p:plain

voyagegroup.connpass.com

 最終回もサービスサービス♪

techlog.voyagegroup.com

PR枠

 エンジニア本大賞にもノミネートされてるので良かったって思った人はぜひ投票よろしくおねがいします!

そーだいなるVOYAGE GROUPの裏側 #DS エンジニアによるビジネスのための機械学習

 今日も@soudai1025 こと id:Soudai がお届けします。

 そーだいなるVOYAGE GROUPの裏側は #voyagebook のイベントとして、各事業部のエンジニアにパネルディスカッション形式で話をしていく企画です。 第五回の今回は「エンジニアによるビジネスのための機械学習」と題してデータサイエンスチーム(以下 DS)のみんなとディスカッションしてきました!

f:id:tan2jpn:20201109134244p:plain

当日の紹介資料

 資料の中にDSの紹介やパネラーの自己紹介もあります。

 質疑応答の内容に合わせたツイートなどのまとめはこちら。

togetter.com

 実際のパネルディスカッションの様子は上記の動画をどうぞ。 今回は機械学習を専門に扱っていないエンジニアでも楽しめる内容でしたね。

 西林さんとところてんさんのわかりやすい解説は必見です! おすすめポイントである、そーだいさんの「なるほど…(わかってない)」を探してみてください。 今回は七色のなるほどが炸裂しています。

感想

 今回はZucksのDSのお話でした。 特にソフトウェアエンジニアとデータサイエンスの橋渡しについて、参考になるところも多かったのではないでしょうか。 Zucksはサバンナと第二回でも話題になりましたが、DSも例外ではありません。 Zucksの中でデータサイエンスをするというのは機能を選定し、モデルを考え、自分たちで実装して、そして運用する。 フルサイクルエンジニアであるからこそ、データから実装までコントロールできる強さを感じました。

 機械学習エンジニアは共感の嵐、ソフトウェアエンジニアとしても学びの多い回でした。 ぜひ、みなさんも見てください!!

次回予告

 次回のそーだいなるVOYAGE GROUPの裏側は サポーターズ です! 「ドアノブを回すと風呂の底が抜ける」そんなパワーワード満載のリプレースを乗り越えたサポーターズ。 事業責任者も巻き込んだパネルディスカッションは盛り上がること間違いなしです!

 みんなも気になるフルリプレースの裏側とその後、赤裸々に切り込んでいきます。

voyagegroup.connpass.com

 見知らぬソースコードに苦戦するサポーターズ。そこに現れたのは…次回「発進!サポーターズ」この次も!サービスサービス♪ 次回のサポーターズ回もよろしくおねがいします!

techlog.voyagegroup.com

そーだいなるVOYAGE GROUPの裏側 #VLS 数十万記事のメディアをゼロから立ち上げる

 今日も@soudai1025 こと id:Soudai がお届けします。

 そーだいなるVOYAGE GROUPの裏側は #voyagebook のイベントとして、各事業部のエンジニアにパネルディスカッション形式で話をしていく企画です。 第四回の今回は「数十万記事のメディアをゼロから立ち上げる」と題してVOYAGE Lighthouse Studio(以下 VLS)のみんなとディスカッションしてきました!

f:id:tan2jpn:20201027132206p:plain

当日の紹介資料

 資料の中にVLSの紹介やパネラーの自己紹介もあります。

speakerdeck.com

 また当日話題にしたSSGからSSRにリプレイスしていった実際の中身について えびちゃん @co3k がまとめてくれています! SEOの知見やSSRの知見を赤裸々に綴ってくれていますのでこちらもぜひご参照ください。

techlog.voyagegroup.com

 質疑応答の内容に合わせたツイートなどのまとめはこちら。

togetter.com

 実際のパネルディスカッションの様子は上記の動画をどうぞ。 今回は「アウトプットとフィードバック」が裏テーマだったと思います。 人を育てるということ、事業を前に進めること、共通してアウトプットを素早く出して、早く結果を出し、そのフィードバックを受け取った上で改善してまたアウトプットを出す。 このサイクルを如何に早く回すかに勘所があるなと学びました。

 リーンスタートアップやMVP*1と同じような文脈ではあるのですが、実際の赤裸々な体験談と共に聴くと、より実感できる内容でした。 特にプルリクエストに対するコメントの話などは同じく育てる側の人たちにとっても学ぶところが多かったのではないでしょうか。  

感想

 今回は事業を0→1にするために技術で問題を解決していく話でした。 その中で前述したとおり、小さくアウトプットしてフィードバックを早く受け取るのが肝要というのは多くの人にも共感する部分なのではないでしょうか。

 また @makoga さんの意思決定のコツも知見の詰まった素晴らしい話でしたね。 私もCTO時代はこの視点をとても大事にしていたので共感がとてもありました。

 ちなみに意思決定に時間がかかるような決定事項に アーキテクチャの決定 があります。 そう考えるとVLSがSSG*2からSSR*3に移行する決断をするのに時間をかけたのも納得できます。

 今回はこれからの自分のエンジニア人生に大切なことがたくさん詰まった回でした。 ぜひ、みなさんも見てください!!

次回予告

 次回のそーだいなるVOYAGE GROUPの裏側は DS*4 です! 機械学習がブームからコモディティ化してきた昨今、如何に実務でデータを活かしているか?という視点で現場の声を聴いていきたいと思います。

 しかも今回は特別ゲストで @tokoroten さんの登場です! 機械学習に興味がある人はもちろんのこと、データサイエンティストじゃなくてもソフトウェアエンジニアなら必見の内容間違いなしですよ。

 私も自分の知らない領域の話を深堀りできるのでとても楽しみな回です!!

voyagegroup.connpass.com

 行き過ぎやりすぎストライク、すでにターキーまで行っちゃってるへっぽこ実験アニメ「VLS」 次回のDS回もよろしくおねがいします!

techlog.voyagegroup.com

*1:Minimum Viable Product: 必要最小限で製品をリリースする

*2:Static Site Generator

*3:Server Side Rendering

*4:データサイエンティスト

ゲーム攻略メディア「神ゲー攻略」の記事配信システムを、五年の歴史がある SSG から二年の歴史がある lit-html による SSR にリプレイスした話

VOYAGE Lighthouse Studio の海老原 (@co3k) です。

ゲーム攻略メディア「神ゲー攻略」の記事は、これまで SSG (Static Site Generator; 静的サイトジェネレータ) を用いて構築、配信されていました。 このたび、従来の SSG を活用した記事配信の仕組みから、 SSR (Server Side Rendering) による仕組みにリプレイスしていくことにしました。

本記事では、そうした新しい記事配信システムの詳細と、移行にまつわる工夫や苦労話などについてご紹介します。

[PR] 本エントリをお読みいただく前に

そもそもリプレイス前の構成ってどんな感じだったの? というか「神ゲー攻略」って何? みたいなのが気になって記事が読み進められないかも〜とご心配の方に耳寄りな情報です。

実は「神ゲー攻略」の事業やシステム構成については『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』の第四章にて、 t-wada さんインタビューのもと、事業背景から技術戦略に至るまで、たっぷりとお話をさせていただいています。

そういった部分も含めてガッツリ理解したいよーという方におかれましては、是非書籍をお買い求めいただければ、この記事を 360° お楽しみいただけると確信しております。

『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』は、私たちのチーム以外にも、 VOYAGE GROUP の大小様々なチームにおける赤裸々な話に触れられる、とても面白い書籍なので、もしまだお読みでない方はこの機会にお手に取られてはいかがでしょうか。

もちろん、本記事は書籍をお持ちでない方でも問題なくお楽しみいただけます!

記事配信システム構成図

まずは全体像を把握していただくために、神ゲー攻略の記事配信システムに関する構成図をババーンとお見せいたします。

f:id:co3k:20201022101026p:plain
神ゲー攻略記事配信システム構成図

図において、青字で解説しているのが旧配信システムに関するものです。

旧配信システムの流れを一言で表現すると、「SSG によって構築された HTML を Amazon S3 に置いて Amazon CloudFront で配信している」です。旧配信システムについては、前述の『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』の第四章で詳しく述べていますので、是非ご一読いただければと思います!

赤字で解説しているものが、本記事においてこれから述べる新配信システムに関するものとなります。

書籍のなかで詳しく説明しているとおりとなりますが、私たちのサービスは検索エンジンからの流入を中心としているため、 SEO (Search Engine Optimization; 検索エンジン最適化) や応答性能などは最大の関心事です。また、事業展開上、旧配信システムにおける簡易なアクセス制御では不足するような事態が出てきていました。新配信システムにおいては、これら要件を満たすための趣向が凝らされています。それぞれについて見ていきましょう。

新配信システムの特徴その 1: lit-html を利用した SSR

旧配信システムは完全なる SSG でしたが、新配信システムは SPA (Single Page Application) に生まれかわっています。これはできるだけ記事のみを無駄なく配信することによるユーザ体験の向上と、転送量等の削減によるコストメリットを狙ってのことです。

さて、 SPA には SEO において懸念があることもよく知られています。

たとえば Google の検索エンジンのボットは JavaScript を解釈しますが、それはレンダリングフェーズにおける話で、クロールフェーズにおいては HTML のみが解釈されます。レンダリングはクロールとは別なキューによって改めて処理されますから、 SPA 技術によって構築されたページがインデックスされるまでには、それぞれの順番待ちの時間が生じることになります。

以下は JavaScript SEO の基本を理解する | Google 検索デベロッパー ガイド | Google Developers 内、「Googlebot が JavaScript を処理する仕組み」 にて紹介されている図となります。この図をご覧いただければどういうことなのか一目瞭然だと思います。

Googlebot が JavaScript を処理してインデックスするまでの図

先述の通り、私たちのサービスは検索エンジンからの流入を中心としており、かつ、競合他社様との競争力も求められることから、こうしたタイムラグは事業的に見て致命傷となりかねません 1

ですから SSR あるいは Dynamic Rendering といった選択肢が検討の俎上に置かれることとなります。しかしながら、

  • Dynamic Rendering はヘッドレスブラウザを用いたレンダリングをおこなう
  • SSR は DOM レンダリングなどをおこなう

という特性から、従来型のウェブアプリケーションに比べ、サーバに求められる性能要件が跳ね上がります。

これらのソリューションはメモリをそれなりに要求しがちです。ウェブサーバ (ないし Dynamic Rendering をおこなうためのリバースプロキシ) のプロセスあたりに要求されるメモリ使用量が大きくなるということは、ひとつのサーバインスタンスで捌けるリクエスト数が少なくなるというトレードオフを覚悟することになります。また、私たちのように Google App Engine を用いる場合は、デフォルトの F1 インスタンスでは不充分で、少なくとも F2 以上のインスタンスクラスでなければたいていの場合まともに動作させられないでしょう。低く見積もって F2 インスタンスを用いるのだとしても、 F1 インスタンスと比べてかかるコストは倍になります。これは PV あたりの運用コストに関わりますし、ひいては収益性に直結します。

幸いなことに、私たちのサイト構成はとてもシンプルです。記事数こそ数十万、月間 PV 数は数億という規模のサービスではあるものの、このシステムで配信されるページは概ね以下の数パターンしかありません。

  • 記事詳細ページ (トップページも含む)
  • 記事一覧ページ
  • その他システムで使うページ (エラー画面など)

これくらいの複雑さのアプリケーションであれば、 React や Vue.js などのメジャーなフレームワークを利用する以外にも、 lit-html が検討候補にあがってくるかと思います。 lit-html は端的に言えば DOM の差分更新をサポートした軽量なテンプレートエンジンです。コンポーネント機構は有しませんが、充分に小さいライブラリなので、ブラウザネイティブの Web Components と組み合わせて利用することができます。

ということで私たちもご多分に漏れず lit-html と Web Components を組み合わせつつ、状態管理を Redux に任せるような形で SPA を実現しています。

さて本題の SSR ですが、 lit-html それ自体は現行バージョンにおいては SSR をサポートしていません。「現行バージョンにおいては」、と書いたのは、次のメジャーリリースである lit-html 2.0 において SSR 可能になるような改良がおこなわれるからです。素晴らしい! ……ですが私たちは未来に生きていないので、どうにかして今すぐに lit-html で SSR したいよーというワガママニーズを満たす必要があります。

さて先ほど lit-html は「軽量なテンプレートエンジン」である、と言いました。 lit-html の解釈するテンプレートは以下のような単純な Tagged Template Literals によって実現されます。

const template = html`<p>Hello, ${name}!</p>`;

現行の lit-html は DOM 実装なしにサーバ上に持っていって動くような代物ではありませんが、 このテンプレート自体を解釈して DOM なしで処理をするような互換実装さえあれば、クライアントとほとんど同様の出力内容をサーバ上で構築することができます。

f:id:co3k:20201023065143p:plain

で、ありがたいことにそのような互換実装が (サードパーティのものですが) あります。 https://github.com/popeindustries/lit-html-server

この実装によってサーバ側での DOM 実装の導入などなしに SSR が実現できる (なぜなら単純な文字列処理に落ちるので) ので、お安く SSR することが可能となります。 もちろん、テンプレート以外にも、たとえばルーティングを router5 のような universal なライブラリによって、クライアント側とサーバ側で共通のルールで処理をさせるなど、クライアント側処理とサーバ側処理の乖離を小さく留めるように工夫しています。

新配信システムの特徴その 2: RDBMS まで来たら負け

新配信システムではなんと RDBMS に記事データを蓄積するようになりました!!!! 五年の時を経てついに普通の Web アプリケーションになった!!!!

例によってフルマネージドなサービスということで、 Google Cloud SQL 上で動かされる MySQL サーバを使っています。

ですが、エンドユーザから参照されるデータの大部分は Google Cloud Datastore から取得するようにしています。 Google Cloud Datastore は高い性能を誇るフルマネージドな NoSQL データベースサービスです。

実は Google Cloud Datastore については、静的な記事ページに動的に埋め込まれるコメント機能のサーバ側実装 2 で既に使い倒しており、その性能は折り紙付きでした。極めて高いスケーラビリティと応答性能、そして強力な可用性は、私たちのような高トラフィックサービスのバックエンドとして据えるにふさわしいものです。

一方で、 Datastore 内のデータをマスタデータとはしていません。マスタデータはあくまで RDBMS に置かれます。これはコメントサーバを実装、運用するなかでの反省から来たものです。

Datastore が Datastore であるために、すなわちその性能要件を維持するため、たとえば RDBMS で可能となる柔軟な条件による結果セットのフィルタリングなどはおこないにくいといった制約が存在します。

たいていの場合、この制約に合わせてアプリケーションを設計、実装することは可能です。しかし、管理画面など、運用上の要求により、柔軟な、時としてアドホックな条件でのデータアクセスが想定されるような場合には、こうした制約がネックとなってきます。コメントサーバにおいては、実際にこれが問題となり、管理上の柔軟性を欠いてしまっている部分があります。

ですので、マスタデータは MySQL 上に、そこから公開用データのみを Datastore 上にそれぞれ格納することで、用等に応じて両データベースを使い分け、双方の利点を享受できるようにしています。

これはパフォーマンス、運用上の柔軟性の獲得といったメリットだけでなく、セキュリティ上の利点ももたらします。

記事のメタデータのなかには編集上のためだけに有用な、公開に差し支えるような情報も含まれます(たとえば、編集担当者のアカウント名など)。このような情報がアプリケーションロジックの問題によって、 API や HTML 出力などを通して誤って公開されてしまうような事態はなんとしても避けねばなりません。あらかじめ公開を意図したフィールドのみに限定したスキーマを持つデータとして射影して格納しておけば、アプリケーションロジックの欠陥によってこれらの情報が誤って公開状態に置かれる可能性を大きく減じられます。

また、 Datastore に至る前には memcached で、さらにその手前では高いキャッシュヒット率 (なんと 90% オーバー) を誇るエッジサーバキャッシュによって、大半のリクエストを処理することができるようにしています。その結果、サイト規模の割に RDBMS への参照がおこなわれることはほとんどありません。そうしたこともあって、エンドユーザのリクエストが RDBMS に来たら「負け」、という思想の元でアプリケーションを組んでいます。

実は、なんと Cloud SQL に関しては一番低いインスタンスタイプで運用されています。チューニングもぜんぜん頑張っていません。にもかかわらず Cloud SQL の CPU 使用率は少ない値を維持し続けており、この工夫が少なくともいまのところはうまくワークしている様子がうかがえます。

f:id:co3k:20201023065202p:plain

新配信システムの特徴その 3: 管理機能は RBAC (ロールベースアクセス制御) による権限管理を実施

攻略サイトで扱う攻略情報のなかには、ゲームのデベロッパ様やパブリッシャ様自身の監修を受けて公開するものも存在します。 そういった情報は、たとえば特定の公開日時までは関係者外秘となるような情報であったりするわけです。

神ゲー攻略の認知度がありがたいことに高まってきたおかげもあり、こうした形態の攻略情報を扱わせていただくことも増えてきましたが、これは旧配信システムで実現するのが(システム的には)難しい要件のひとつでした。旧配信システムは大ざっぱに公開用バケットと非公開用バケット、二種類のバケットに対するデプロイにしか対応しておらず、「特定の関係者のみに公開する情報」や「特定種類の情報しか閲覧できない関係者」などといったきめ細やかなアクセスコントロールは残念ながら実現することはできませんでした。

新配信システムにおいてはこの課題を払拭するために RBAC (ロールベースアクセス制御) による権限管理を実施しています。 これによって、以下の図のように(わかりにくいかもごめんなさい)、個々のロールに対して複雑な権限設定を付与するというのが簡単におこなえるようになっています。

f:id:co3k:20201023065217p:plain

ちなみに、 RBAC の実現にあたっては Casbin というライブラリを用いています。

実装コードの具体的な内容は Casbin 自体の知識がかなり要求されてしまいますので割愛しますが、上の図のようなことをおこなう Negroni の middleware を用意していて、各 API のエンドポイントよりも手前で処理されるようにしています。

リプレイス戦略——いきなり移行はせず、新配信システムを、独立したサブシステムとして稼働させる

さて、こうした機能を備えた新配信システムにリプレイスしていくわけですが、なにぶん大きなアーキテクチャ変更を伴うリプレイスですので、やはりというか何というか一筋縄ではいきません。

旧配信システムはだいぶガタが来ているとはいえ、五年もの歴史があります。安定性や稼働率も抜群ですし、現場で運用するうえでの工夫もたくさん詰まっています。これを一朝一夕でまるごとすげ替えることはできません。いえ、表面上はできるかもしれませんが、配信性能や記事品質など、私たちが大事にしている多くのものをしばらくの間犠牲にすることになるでしょう。

ではどうしたかというと、最初は「リプレイスをしない」という決断をおこないました。

リプレイスは決して簡単な道のりではありませんから、旧配信システムとはまた別な形での記事配信システムとして新配信システムを立ちあげ、新規に構築するタイトルの一部や、新配信システムによって新たにもたらされる管理機能などが有効に働くゲームタイトルの一部などで実験的かつ段階的に導入をおこない、編集部側で運用するにあたっての知見やフィードバックの収集、開発側での技術やシステム運用に関するノウハウの蓄積、そしてもちろんバグの洗い出しと修正や、徐々に増えていく負荷にあたって支障が出てこないかなどを焦らず慎重に進めていきました。

どのくらい慎重かというと、実は 2 年前に書いたエントリ、スキーマ定義言語 Protocol Buffers と protoc-gen-swagger を使って Web API のスキマを埋めようにて触れている「とある派生サービス」というのが、この新配信システムのことだったのです。

な、なんだってーっ(AA 略)。

ということで、新配信システムは、実際に旧配信システムからリプレイスされるまでに、 2 年近く battle-tested な状態に置かれていたということです。これだけの期間があれば、わかりやすいバグは潰れているし、運用側での知見もだいぶ蓄積されています。どこの馬の骨ともつかないシステムに、開発と編集の両方が振り回され、高い品質の記事を安定した配信基盤に載せて素早く出す、という目的が達成できない、……という事態にはならずに済みます。

そうそう、要するにこの戦略は、あたかも一個のサービスの看板を出しておきながら、その実、二種類のシステムを抱えていて、条件に応じて切り替える、というようなモデルなんですが、これが気軽にできてしまうのは、見た目上の違いをほとんど感じさせないように作っているというものあるでしょうが、ゲーム攻略サイトならではの特徴のおかげかもしれません。ゲーム攻略サイトは「検索エンジンからの流入が中心」、「ゲームタイトルごとにユーザが分かれる」という特徴があります。特に後者が重要で、たいていの人は複数のゲームを本当の意味で同時にはプレイしません。従って『AJITO 奪還大作戦』3というゲームをプレイしているときに『Enemy in VOYAGEー船に乗り込む侵入者たち』4というゲームのことを調べたくなったりはあまりしないわけです。それぞれのゲームタイトルごとに攻略サイトが立ち上がっているというような認識をもたれるのがむしろ普通なので、それぞれが別なシステムで動いていたとしても、そもそもそんなに気にならないという土壌が既にあるのだと言えます。

よくある質問 Q1: あれ? ということは、リプレイスはまだ終わっていないってこと?

は、はい……。

旧配信システムから記事などのリソースをインポートして新配信システム上で利用できるようにする仕組みは既に用意しています。 この仕組みを利用して、 100 を超えるゲームタイトルについては、既に旧配信システムから新配信システムに切り替えて記事の配信がおこなわれています。

以下が、実際に記事をインポートしている様子です。

f:id:co3k:20201023123010p:plain

新システムにおいても、 Markdown パーサやそれに付随する CSS や JavaScript のアセット類の一部については、旧システムのものをそのまま移植しています。そのため、記事の内容に踏み込んだ変換処理などは一切おこなっていません。

旧システムは Markdown の表現力を活かしまくってメニューなどを実装しているため (なぜかというとそうするしかなかったからです)、そのあたりを新システムに適合するようにインポートするなど、小さな差異は埋めていく必要がありますが、基本的には新旧システム間でのリソースの互換性を維持するように配慮しているため、このインポート用のコマンドラインツールはもっぱらオートメーションのために機能している具合となります。

また、この切り替えについても一気にはおこなっていません。準備が整ったゲームタイトルから、新配信システムを利用する形に少しずつ移行を進めていっています。 万が一移行に際して致命的な問題が生じたとしても、影響範囲が小さく抑えられるようになっています。

ただ、運用ツールがガラリと変わってしまうため、移行については、システム側での準備だけでなく、運用側での準備が必要不可欠です。 たとえばゲーム内イベントはたくさんのユーザが訪問してくれる大事な機会なわけですが、そのようなチャンスを、私たちの都合によるシステム移行作業で逃してしまっては悔やんでも悔やみきれません。

ということで、ただいま大絶賛リプレイス進行中というわけです! えへん。

え、えへん……

……な、なんだか煮え切らない感じの締めになってしまってすみません。でもこれがありのままの現状なんです。

えっ? こういうありのままの赤裸々な話をするのにうってつけなイベントがあるって本当ですか!?

[PR] 「そーだいなるVOYAGE GROUPの裏側 #VLS 数十万記事のメディアをゼロから立ち上げる」というイベントをやります!

『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』出版イベントである、大好評「そーだいなるVOYAGE GROUPの裏側」の第四弾、 VOYAGE Lighthouse Studio 編が、来る 10/26 (月) の 12:30 より(オンライン)開催されます!

https://voyagegroup.connpass.com/event/192112/

この記事の内容や書籍の第四章の内容であったり、あるいはあまり触れられていなかった部分などについて、どんどん掘り下げていくタイプのイベントとなっています。

特に、本記事においては、旧システムの問題点や、どうして新システムへのリプレイスを決断するに至ったのかについてはあまり触れませんでした。そのあたりが気になる方については、『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』をお読みいただいてももちろんいいのですが、このイベントにおいても、そーだいさん(@soudai1025)にモデレータを務めていただくことで、より深く生々しい苦労話などが明らかにされるはずです。

ということで、興味を持たれた方は是非ご参加いただけると嬉しいです。質問も絶賛受け付け中ですよ!


  1. このあたりのお話はぜひ『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』にてお楽しみください。

  2. 『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』 132 ページ参照

  3. タイトルは架空のものです。同名の何かが万が一実在したら申し訳ございませんが、それは偶然の一致であって実在のものとは無関係です

  4. タイトルは架空のものです。同名の何かが万が一実在したら申し訳ございませんが、それは偶然の一致であって実在のものとは無関係です

そーだいなるVOYAGE GROUPの裏側 #VM 編 レガシーシステムといい感じに付き合うスキル

 今日も@soudai1025 こと id:Soudai がお届けします。

 そーだいなるVOYAGE GROUPの裏側は #voyagebook のイベントとして、各事業部のエンジニアにパネルディスカッション形式で話をしていく企画です。 第三回の今回は「レガシーシステムといい感じに付き合うスキル」と題してVOYAGE MARKETING(以下 VM)のみんなとディスカッションしてきました!

f:id:tan2jpn:20201017175212p:plain

当日の紹介資料

 資料の中にVMの紹介やパネラーの自己紹介もあります。 どんな会社なのか気になる!って人もぜひ資料を見てみてください。 オススメポイントは人気声優と同姓同名の下りです!*1

speakerdeck.com

 質疑応答の内容に合わせたツイートなどのまとめはこちら。 togetter.com

 実際のパネルディスカッションの様子は上記の動画をどうぞ。 3回目ともなるとこなれてきて、いい感じに雑談から入り、配信もできました。 パネルディスカッションも大盛りあがりだったのでぜひ見てください!

 今回は牧場のfluct、サバンナのZucks、に対して農耕と評される、VMの話でした。 チームで問題に取り組み、チームで問題を解決するという文化が終始出ていましたね。

 特にレガシー改善は古いコードのメンテナンスをさせられているという印象が強いですが、そんなことはなくてどんどん新しい仕組みを取り入れたり、置き換えたりしながら前に進んでいて、多くの人に勇気を与える回でした。  

感想

 今回は自分の中では大きく以下の3つのテーマがありました。

  • 歴史あるサービスをメンテナンスするということの楽しさと学び
  • レガシーコードを腕力*2ではなく、組織で取り組む
  • 改善の道に王道なし、プロダクトの成長に近道なし!

 この3つがVMの特徴だと思っていて、皆様にその片鱗をお伝えすることができたのでは無いでしょうか。 特にこのツイートがVMの文化を表してるなぁと感じます。

 VMの文化はチームにフォーカスしているものの、前述の2社と変わらず、事業の成長にエンジニアが向き合ってきた形です。 お互いにサポートしながら 一つのミッションをチームで解決する というミッションベースの文化は多くの企業でも取り入れる要素なのではないでしょうか。

 今回の回も名言が連発なのでぜひTwitterのまとめも御覧ください。

次回予告

 次回のそーだいなるVOYAGE GROUPの裏側は VLS*3 です! ここまで1を100にする、100を10000にするような事業の話がメインでしたが次回は0を1にする話です。 今までは腕力あり、文化ありですが次回はそこにまさに 技術あり! といった内容になる予定です。

 最小限で最大の効果を発揮する、技術で問題を的確に解決していくVLSの姿に乞うご期待ください。 本の中で語られなかったより深い技術の話を引き出せると思うとオラ、ワクラクしてきたぞ!

voyagegroup.connpass.com

 VMに変わってお仕置きよ! 次回のVLS回もよろしくおねがいします!

techlog.voyagegroup.com

*1:当日誰も触れなかったのでここで触れます

*2:腕力についてはfluct回を参照

*3:VOYAGE Lighthouse Studio