今年もRubyKaigiが始まりましたね！noteはrubyスポンサーとして協賛しています。三重の会場にきている方は、ぜひnoteのブースにも足を運びください。 さて、noteはRuby on Railsを用いたwebサービスとして2014年にリリースされました。現在でも継続してRailsのコードベースを利用しています。 しかし、多くの機能がリリースされ、開発者も増えたため、モノリスの巨大化が進んでおり、開発効率に影響が出始めていました。 今回はそれらの問題を解消するために、noteが継続的に取り組んでいる・取り組んできたバックエンドの改善プロセスについて説明していきます。 モジュールでサービスを構成するモノリスは大きくなるとメンテナンスが難しくなります。Railsは、MVCの各層に全てのドメインがフラットに並び、レイヤごと・レイヤ間の結合度が高くなる設計思想で、巨大モノリス化への対処が難

このポエムでは、IT屋なら避けては通れない障害について話してみたいと思います。 システム障害と体験的障害システムの安定性を表す指標としてSLAが業界でよく使われています。これは、障害時間を稼働時間で割ったパーセンテージでして、99.9％以上正常稼働するならスリーナインが保証されているシステム、といった感じで使います。 これはこれで便利でわかりやすい指標です。しかし、個人的には、サービス運営においてはこういったシステム障害に関する紋切り型な指標だけを拠り所にする運用は避けたほうが無難と考えています。 たとえば、あなたはCtoCのSNS系サービスを運用しているとします。このとき、障害をもっと大きく捉えると.... ・コンテンツを投稿して数時間たっても何も反応がない ・おすすめコンテンツ紹介メールが送られてきたので開封してみたが、なにも刺さるコンテンツがなかった ・読み込みが遅くてストレスが貯ま

こんにちは、ピースオブケイクのコンです。先週、noteのドメインがnote.muからnote.comに移転されました 移転の詳しい背景はこちらの記事を参照いただくとして、本稿では技術的側面からこのドメイン移行について振り返ってみます 2000万MAUのサイトを移転する技術webサービスがドメインを移転する事はたまにある...といえばあるでしょうが、noteのようにそれなりに複雑で、2000万MAUもあるサイトをドメイン移転するというのは聞いたことがありません。 2019年2月にcomを取得後、具体的に移行の作戦を考え始めたのですが、ググって成功事例を探しても「理屈は分かるけど、ウチの規模だと、どこにどう影響出るか完璧に把握するのは難しいな...」と思いました。それでもやるしかない状況だったわけです。 なので、今後、ドメイン移転を実施するサービスのスタッフ（特にエンジニア）さんの参考になれば

webサービスのUXを向上させるために、表示速度は非常に大切です。 しかしながら、noteはリリース当初からフロントエンドの実行速度が遅い=表示が遅いという構造的な問題を抱えており、継続率や離脱率など重要指標に悪影響を及ぼすリスクが強くありました。 noteチームはnoteを本格的なメディアプラットフォームへ成長させるスピードを加速していきます。それを踏まえ、手遅れになる前に技術的な負債を解消し、最新のベストプラクティスに沿ったフレームワークに移行することで、高性能なサービスを提供する基盤を作っていくという決断をしました。 本ポストでは、移行プロジェクトの技術的背景や移行手順を説明します。また、途中成果のデモをUPしているのでご紹介します。 技術的な背景noteの現在のフロントエンドはAngular.js 1系で構築されたSPAです。Angular 1系はかなり複雑なUIでも簡単に構築でき

javascriptの開発では、sassやtypescriptなどのコンパイル、minifyやautoprefixerでの最適化、依存関係を解決しbundleするなど多様な工程があるので、属人化・職人依存を避けるためにタスクランナーでの自動化が昔から当たり前に行われています。 webpackはこの手のツールのデファクトです。webpackはタスクの自動化支援ではなく、なんでもjsにまとめるという仕事をうまくやる事に特化しています。gulpやbrowserifyで行なっていたようなタスクの自動化はnpm scriptで十分やん、という割り切りを感じます。 なんでもjsで扱えるようにするので、cssや画像やhtmlもjs内にロードでき、設定が煩雑になりにくくなります。 webpackのloaderという仕組みがjsへの組み込みや最適化をうまくやってくれるのですが、どういうものか検証していきまし

世の中にビジネスホテルは多数あって激しく競争しているわけだが、エンジニアが泊まるのに適した性質を備えたビジホは限られていると思う。そんな中で、東横インは完璧に技術屋のニーズに応えており頭一つ抜け出ている。それは一体どういうことか？を説明していきたい。 冪等性が完璧に担保されている冪等性が担保されているとは「ある操作を何回実行しても、同じ結果が返ってくる、同じ状態になる」という意味で、ソフトウェアが備えているべき重要な性質の一つである。 なんと、東横インは全国各地どこに泊まっても、結果が同じになる。部屋や家具のレイアウト、シャワーの温度や水圧、朝食、アメニティ、ベッドや照明の具合など、それこそコンピュータのような精緻さでどの館も同じである。チェーンなので統一感があるのは当たり前なのだが、それを超えて区別不能の域に達している。 エンジニアのメンタルモデル的には、コマンドが期待通りのタスクだけを

Herokuはwebアプリをインターネット上にデプロイする場所として広く使われている。web業界の人は誰もが一度は触った事があると思う。 何が便利なのかというと、デプロイ作業が極めて簡単なことだ。コマンド一発でサーバーが用意され、これまたコマンド一発でデプロイが出来る。一般に、webアプリは依存するライブラリが多種多様あり、それらを漏れなくインストールしないとデプロイ出来ないのだが、代表的なwebアプリケーションの作り方に添って作っている限り、後は構成を検知してよしなにやってくれるのだ。noteのリリース時の検証にも大活躍してくれた。 別にHerokuの回し者ではないのだが、一旦これを経験すると、VPSを借りてLinuxのセットアップをしてミドルウェアいれて....といった一般的な構築作業が気の遠くなる工程に思えてくる。 しかし、HerokuはUSとヨーロッパにサーバーがあり、日本からの通

日本経済新聞は国内を代表する経済誌だ。その電子版はwebでの継続課金を大成功させ、いまや50万以上の有料会員を擁するモンスターサイトだ。 その日経電子版が11月6日に全面リニューアルしたのだが、公開後、web業界がにわかにざわついた。表示速度が爆速だったのだ。日経公式もモバイルで2倍の表示速度を達成したと堂々と宣言していた。 webサービスは継続率こそ神KPIで、その継続率には速度が大きく影響する。 これはチェキらないとヤバイと感じ、友人のkitakさんとスピードの秘密を調査してみた。 Fastlyをコンテンツキャッシュに使う殆どのデータはFastlyを経由して取得されていた。Fastlyは最近注目を集めているCDN（世界中にエッジサーバーを配置し、高速にコンテンツを配信するサービス）で、非常に高機能でユニークなサービスだ。 一般に、CDNはいったん世界中にコンテンツをばらまくと、それを無

先月あたりから、オープンソースソフトウェア（以下、OSS）のライセンスのあり方について、Facebookを火種にして侃々諤々の議論が起こっているので解説してみる。 ASFがFacebookにNOをつきつけることの始まりは、Apache Software Foundation（以下、ASF）という著名OSSプロジェクトを多数保有する非営利団体が、Facebookが自社OSSに付加している独自ライセンス Facebook BSD+Patents license を「Category-X」リスト（禁忌リスト）に追加したことだ。 ASFプロジェクトは、Category-Xに含まれるOSSに依存してはいけない決まりがあるため、Facebook製のOSSに依存しているプロジェクトは、8月31日以降はそれらの依存を取り除いてからではないと新しいリリースが出来ない。影響を受けたプロジェクトは少なくとも C

先月、Twitter社が"Twitter Lite"という軽量バージョンを発表した。新興国向けに、2Gや3Gのような低速で不安定なネットワーク下でも快適に使えるように通信量を抑え、動作速度も向上させる、というのがコンセプトらしい。 Twitter Liteのご紹介 https://blog.twitter.com/ja_jp/topics/product/2017/twitter-lite_.html たしかに、初回ロードの読み込みサイズを見てみると、なんと400キロバイト以下しか転送されていない。普通の画像2,3枚分よりも小さく、めちゃめちゃコンパクトである。 それだけ?それだけなら「ふ〜ん、そうなのね」で終わりなのだが、技術的な側面で言うと、じつはTwitter Liteはネイティブアプリではないというのが見どころだ。単なる、普通のwebサイトなのである。mobile.twitter.