「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」を１年掛けて整理した
こんにちわ。rwle1212です。 本記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。 登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので本題に入ります。 50分の登壇内容なので少々長くなりますが、お付き合いください。 JAWS Days 2019で登壇した内容の振り返り昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」という内容で登壇しました。 まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。 そもそもInfrastructure as Cod
Capital Oneデータ漏洩経路の考察
2019年8月に発生した Capital Oneのデータ漏洩事件に関する各種報道等の情報からそのデータ漏洩経路を考察する。FBIの起訴状、CapitalOneの公式発表のほか、インターネット上で報道されている各種情報から考察をしており、内容には推測も含まれる。 なお本考察は個人的な調査に基づくものであり、いかなる公式発表でもなく、技術的な観点から事象や対策について検討したものである。 漏洩したデータS3バケットに保存されていたデータが漏洩した。また非公式な情報では、Twitterで犯行を告知しているメッセージから読み取るに、EBS Volume Snapshotも漏洩した可能性がある。 取得したというデータのリスト (KrebsOnSecurityより)主な漏洩の流れ構成ミスがあったWAF (Reverse Proxyとも)を利用され、その後にS3バケット内にあったデータなどが漏洩した。
Apache Kafkaを使ったアプリ設計で反省している件を正直ベースで話す
Apache Kafka: Producer, Broker and Consumer2017年は生まれて始めてApache Kafkaを本格的に業務利用（PoCではなく本番運用）した年でした。Apache Kafka的なメッセージングミドルウェアそのもののは、社内的な事情でよく使っていたのでその使い勝手に対して困惑はほとんど無かったですし、ミドルウェアとして非常に安定しているため、Kafkaクラスタそのものでの不具合らしい不具合が発生したことは一度もありませんでした。 しかし、Kafkaのトピック設計などに関してのベストプラクティスは事例ベースでもあまり見かけたことがなく、チームメンバーと悩むことも多かったです。このストーリーでは、主にKafkaを利用したアプリ設計で考えたことや失敗したことを振り返りつつ共有します。なお、パーティション数や各種バッファサイズなどのチューニング要素は今回取
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
Logstash を使って MySQL データを Elasticsearch にインデックスする（基本編）
リレーショナルデータベースで管理しているデータを Elasticsearch で検索・分析したい場合、Logstash が便利です。 Logstash とは？Logstash はオープンソースのサーバーサイドデータ処理パイプラインです。様々な数のソースからデータを取り込み、変換し、指定された任意のストア先にデータを格納することができます。 処理の内容はシンプルで、Input ステージでソース元の接続先情報を管理し、Filter ステージで変換をし、Output ステージで格納先接続先情報を定義します。Input 及び Output プラグインはデフォルトで様々なソースをサポートしています。そのため、Logstash を使えば、プログラミングレスで MySQL のデータを取り込み、変換し、Elasticsearch へインデックスすることができるのです。 事前準備MySQL と Elasti
１回目）Elasticsearch 勉強会を開催したので資料公開します。
６月２７日にクラスメソッド事業開発部の開発メンバーとベルトラ開発メンバー合同で Elasticsearch 勉強会１/２を開催しました。参加者はリモートも含めて約２５人くらい。時間は２時間。久しぶりに長時間喋ったので疲れました。。たくさんの人が参加すると聞いていたので、この勉強会のために資料まとめたので公開します。 Elasticsearch 勉強会 1/2 前半全文検索エンジンの特徴について話しました。いきなり「転置インデックス」と言われても、ピンと来ないかもしれませんが。全文検索エンジンの設計を担当する人も、それを使ってアプリケーションを開発する人もこの仕組みを知らなければ Elasticsearch のリファレンスで提供されている機能を見てもピンと来ません。「この機能何に使うんだろう？」となってしまいます。世の中にある全文検索エンジンに標準規格というものは存在しませんが、その仕組みは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
