本日、以下のような文章を読んだ > I was suffered from ~ ~の部分には遭遇した諸問題について書いてあったので、この文章は「苦しめられた」と言いたいのだと推察できた。ただ、残念な事に、be suffered というのは多分現在ではほとんど使わないし、意味が若干違ってくると思う（詳しくは検索してきて！） sufferと言う言葉は「苦しむ・被る」という意味なので、受け身にすれば「苦し『められる』」という意味になるのではないか、というつもりだったのはないかと推察するが、sufferはすでに受け身の意味なので、I sufferですでに何かに苦しめられているのであり、これをさらに受け身にする必要はない。 > I had to suffer from having to deal with spaghetti code とかなら、「スパゲッティコードに立ち向かわなくてはいけなかった

2回目分のメモの続きです。 内容 徳丸本読書会 開発者のセキュリティに関する責任 裁判のガイドラインがIPA 個人情報保護法はどこから適用されるのか HTTPについて URIとスキーム DNSというスキームは無い ベーシック認証の流れ 上記以外で知らなかった用語 セッションIDの固定化攻撃 クッキーモンスター 別人問題 ゼロデイ攻撃 Gumblar リスクの受容 徳丸本読書会 1章から読んでいきました。このあたりは、まだついていけている感じなので薄めです。 開発者のセキュリティに関する責任 セキュリティには機能要件とバグに分類できるものがありますが、昨今ではある程度の標準を満たさないと開発者は裁判で負けます。 裁判の基準は https://www.ipa.go.jp/security/vuln/websecurity.html https://www.ipa.go.jp/files/000

技術部の小野(taiki45)です。クックパッドではこれまで様々なデータベースの負荷対策を行ってきましたが、シャーディングは行われていませんでした。しかし先日クックパッドの認可サーバーが利用している MySQL サーバーの負荷分散のためにクックパッドで初めてのシャーディングを行ったので、Rails アプリケーションでのシャーディングの事例のひとつとしてその際の手法をご紹介したいとおもいます。 構成 Before データベースは1マスター、1ホットスタンバイ、バッチ用の1リードレプリカで構成されています。Read オペレーションのほとんどはキャッシュ層に逃しています。 After データベースの各ロールにつきそれぞれ1台ずつマシンが増えています。 シャーディングが必要になった背景 認可サーバーのアクセストークンの作成・削除時の Write オペレーションが急増し、レコード数自体も急増していて