エンジニアが向き合うべき障害｜こんぴゅ
このポエムでは、IT屋なら避けては通れない障害について話してみたいと思います。 システム障害と体験的障害システムの安定性を表す指標としてSLAが業界でよく使われています。これは、障害時間を稼働時間で割ったパーセンテージでして、99.9％以上正常稼働するならスリーナインが保証されているシステム、といった感じで使います。 これはこれで便利でわかりやすい指標です。しかし、個人的には、サービス運営においてはこういったシステム障害に関する紋切り型な指標だけを拠り所にする運用は避けたほうが無難と考えています。 たとえば、あなたはCtoCのSNS系サービスを運用しているとします。このとき、障害をもっと大きく捉えると.... ・コンテンツを投稿して数時間たっても何も反応がない ・おすすめコンテンツ紹介メールが送られてきたので開封してみたが、なにも刺さるコンテンツがなかった ・読み込みが遅くてストレスが貯ま
noteのドメイン移行を支えた技術｜こんぴゅ
こんにちは、ピースオブケイクのコンです。先週、noteのドメインがnote.muからnote.comに移転されました 移転の詳しい背景はこちらの記事を参照いただくとして、本稿では技術的側面からこのドメイン移行について振り返ってみます 2000万MAUのサイトを移転する技術webサービスがドメインを移転する事はたまにある...といえばあるでしょうが、noteのようにそれなりに複雑で、2000万MAUもあるサイトをドメイン移転するというのは聞いたことがありません。 2019年2月にcomを取得後、具体的に移行の作戦を考え始めたのですが、ググって成功事例を探しても「理屈は分かるけど、ウチの規模だと、どこにどう影響出るか完璧に把握するのは難しいな...」と思いました。それでもやるしかない状況だったわけです。 なので、今後、ドメイン移転を実施するサービスのスタッフ（特にエンジニア）さんの参考になれば
Nuxt.jsでnoteの記事ページを置き換えました｜こんぴゅ
noteの記事ページがリニューアルしてパワーアップしました。記事の読み込み、描画が格段に高速化されています。 noteのフロントエンドはAngular.jsの1系で運用されてきましたが、実行効率が悪く表示速度が遅いという問題がありました（特に古いスマホで顕著）。問題を根本解決するためにNuxt.jsへの移行を進めていました（詳しい経緯は以下の記事をごらんください）。 今年から、おすすめページ、マガジンページ、コンテスト一覧ページなど部分的にNuxt版に置き換えていきました。nodejsやNuxt.jsサーバーの運用が初めてだったので一気に置き換えるのではなく少しづつリリースして様子を見ながら進めました。 運用を2ヶ月ほどしてみて、インフラ面、実装面で問題なさそうなことが確認できたため、noteのトラフィックの多くを占める記事ページ（このページがまさにそうですね）のNuxt.js版リリースを
noteのフロントエンドをNuxt.jsへ刷新します｜こんぴゅ｜note
webサービスのUXを向上させるために、表示速度は非常に大切です。 しかしながら、noteはリリース当初からフロントエンドの実行速度が遅い=表示が遅いという構造的な問題を抱えており、継続率や離脱率など重要指標に悪影響を及ぼすリスクが強くありました。 noteチームはnoteを本格的なメディアプラットフォームへ成長させるスピードを加速していきます。それを踏まえ、手遅れになる前に技術的な負債を解消し、最新のベストプラクティスに沿ったフレームワークに移行することで、高性能なサービスを提供する基盤を作っていくという決断をしました。 本ポストでは、移行プロジェクトの技術的背景や移行手順を説明します。また、途中成果のデモをUPしているのでご紹介します。 技術的な背景noteの現在のフロントエンドはAngular.js 1系で構築されたSPAです。Angular 1系はかなり複雑なUIでも簡単に構築でき
すべてをjsにまとめる思想を理解する - webpackハンズオンシリーズ｜こんぴゅ
javascriptの開発では、sassやtypescriptなどのコンパイル、minifyやautoprefixerでの最適化、依存関係を解決しbundleするなど多様な工程があるので、属人化・職人依存を避けるためにタスクランナーでの自動化が昔から当たり前に行われています。 webpackはこの手のツールのデファクトです。webpackはタスクの自動化支援ではなく、なんでもjsにまとめるという仕事をうまくやる事に特化しています。gulpやbrowserifyで行なっていたようなタスクの自動化はnpm scriptで十分やん、という割り切りを感じます。 なんでもjsで扱えるようにするので、cssや画像やhtmlもjs内にロードでき、設定が煩雑になりにくくなります。 webpackのloaderという仕組みがjsへの組み込みや最適化をうまくやってくれるのですが、どういうものか検証していきまし
実はHerokuで充分なのでは問題｜こんぴゅ
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はいったん世界中にコンテンツをばらまくと、それを無
Facebookの特許条項付きBSDライセンスが炎上している件について｜こんぴゅ
先月あたりから、オープンソースソフトウェア（以下、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 Liteにアプリとwebの未来をみた｜こんぴゅ
先月、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.
冗長化の難しさとNetflixの答え｜こんぴゅ
この世には、ダウンすることが許されないシステムが存在する。金融機関の基幹系、原子力発電所や鉄道の制御システム、流通業の物流管理システムなどはもちろんであるが、最近ではtoCのサービスでもダウンタイムが長くなると大事件として騒がれ、ヤフトピに載ってしまったりする。 ではダウンへの対策はどうするかというと、いくつか手法はあるのだけど代表的なのは「冗長化」である。簡単に言うと、全く同じシステムを裏側に待機系として用意して、有事の際は自動的に切り替わるようにしておくのである。素朴だが、殆どのシステムではこの種の仕組みを用意している。 それでうまくいけばいいのだけどじつは、この待機系への切り替えというのは鬼門であり、高確率で失敗する事になる。 ［続報］東証のシステム障害、原因はハードウエア故障後の切り替えミス http://itpro.nikkeibp.co.jp/article/NEWS/2012
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
