補足: AWS Lambda のコンテナのライフサイクルについては説明を単純化していますので、詳しくは http://www.slideshare.net/keisuke69/aws-lambda-46129981 こちらの 42 ページ以降を参照してください
![Serverless Architecture](https://cdn-ak-scissors.b.st-hatena.com/image/square/18eca89fa5337d24206cf9d108facbd1e5ad95b5/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F185ffca9d9ad4b3aad4b0f8f8f91c284%2Fslide_0.jpg%3F7055091)
アプリケーション/データベースエンジニアであれば、一度はDeadLockという忌まわしい出来事に遭遇したことがあることでしょう。Redshiftのロックについてはあまり詳細な仕様が公開されていませんが、ロックやデットロックの動作について検証した結果について報告します。 トランザクション分離レベルは、「SERIALIZABLE」 大量データのデータのロード(LOAD)と参照(SELECT)に最適化されたRDBといえます。そのようなユースケースを想定して、トランザクションを開始(BEGIN)するときのデフォルトのトランザクション隔離レベルが、「SERIALIZABLE」 に設計されているのではないかと考えています。「SERIALIZABLE」 なので、デフォルト動作では、ダーティリード、ファジーリード、ファントムリード は発生しません。 BEGIN トランザクション分離レベルについて極力分かり
Welcome to the “Container technologies in Fedora” series! This is the first article in a series of articles that will explain how you can use the various container technologies available in Fedora. This first article will deal with systemd-nspawn. What is a container? A container is a user-space instance which can be used to run a program or an operating system in isolation from the system hosting
CEDEC+KYUSHU 2016で発表した資料です サイバーエージェントの子会社群からなるゲーム事業(SGE) 技術戦略とエンジニアを成長させる仕組みについてのお話です
こんにちは。トゥギャッター株式会社でバックエンド中心にエンジニアをしている @MintoAoyama です。 Togetter はツイートを始めとした様々な情報を組み合わせてコンテンツを作り出すキュレーションサービスです。 2009年に誕生してから今年で8年目に突入し、現在も月間6000万PV・1200万UUを超える規模で成長を続けています。 海外版の Chirpstory も政治家・公共団体・ジャーナリストなど影響力のあるユーザに支えられ、成長を続けています。 そんなTogetter・Chirpstoryを支えるシステムの1つに 画像配信サーバ があります。もう少し詳しくすると リアルタイム変換機能付き 画像プロキシサーバ です。 この仕組み、特に当サービスにおいては地味に重要な役割を持っているのですが、社内に関心を持って貰える人が居なかった(※)ので、とりあえずここに整理することにしま
Container Integration Since a while containers have been one of the hot topics on Linux. Container managers such as libvirt-lxc, LXC or Docker are widely known and used these days. In this blog story I want to shed some light on systemd's integration points with container managers, to allow seamless management of services across container boundaries. We'll focus on OS containers here, i.e. the cas
フォーカスするためには、たぶんどうやってフォーカスするか(前回)に加えて、何にフォーカスするかを決める必要があって、今回は後者、つまり「フォーカスポイントを決める」方の話です。 スタートアップの初期は Y Combinator 的に言うところの Do things that don’t scale (スケールしないことをしよう)をはじめとした明確なフォーカスポイントがあると思います。ただ次第に自分たちでフォーカスポイントを決めなければいけなくなってきて、そのときにどのようにフォーカス先を意思決定すれば良いのか、どうすれば良い意思決定ができるのか、という問いが出てきて、その際に方法論の必要性が生じます。 そこで意思決定の方法論を検討するのですが、スタートアップのような情報不足や資源の制約下では、ゲーム理論をはじめとしたいわゆる規範的な normative 意思決定理論よりは、行動経済学や認知
GitHub: haya14busa/reviewdog: A code review dog who keeps your codebase healthy 英語記事: reviewdog — A code review dog who keeps your codebase healthy – Medium reviewdog というlinter などのチェックツールの結果を自動で GitHub の Pull Request にコメントしたり, ローカルでも diff の結果から新たに導入されたエラーだけを表示するようにフィルタリングできるツールを作りました. 英語記事 を Medium に書いたし,README も書いたので 日本語記事はまぁいらないかなぁと思ったけど,柄にもなく Vim 関連以外で普通に便利ツールを書いてしまって,これは日本語でも簡単に共有しようかなぁと思いこの記事
t-wadaさんとのSQLアンチパターン勉強会 はじめにこんにちは、技術開発部の中森です。 社内で4ヶ月に渡り、SQLアンチパターン勉強会を開催してきました。そして、最後の締めとして、SQLアンチパターン監訳者であるt-wadaさんをお迎えし、今までの勉強会で疑問として上がった点について、討論会を行いました。 今回のエントリではその討論会の内容を紹介します。 ファントムファイルについて勉強会の中で最も議論となったのは11章のファントムファイルでした。 この章で紹介されているアンチパターンは、ファイルのバイナリ情報をDBの内部に保存するのではなく、外部のファイルに置くというものです。 t-wadaさん曰く、他の場所でも最も批判の対象となる箇所です。 ここで最も大切なことは「盲目的にアンチパターンを避けない」ということです。 最近のWebアプリケーションでは画像や動画のバイナリデータは頻繁にや
昨今のウェブアプリケーションでは、ほとんどの場合、オープンソースのフレームワークやライブラリのような、自社開発ではないパッケージ化された部品(コンポーネント)を組み合わせて構築することでしょう。ですから、もしも既知の脆弱(ぜいじゃく)性が存在するようなコンポーネントを利用してウェブアプリケーションを開発していた場合には、組み込まれたコンポーネントの脆弱性を悪用され、攻撃を受けてしまう可能性が高くなります。 本稿では、ウェブアプリケーションに組み込まれている脆弱性が存在するコンポーネントの洗い出しに有用な、OWASPコミュニティより公開されているツール「OWASP Dependency Check」の概要および利用方法について解説します。 はじめに 本連載の第1回では、ウェブアプリケーションにおける重要なインパクトのある10のセキュリティリスクについてまとめた「OWASP Top 10」につ
執筆者 執筆者:數見拓朗 所属部署:技術本部 秋葉原ラボ 業務経歴:トレンド検知システムやスパムフィルタの開発・運用、Amebaと広告配信のデータ分析業務を担当。 概要 機械学習は、データの複雑な関係を明らかにし、未知データの予測や特徴の発見を得るのに有用である。しかし、一般に提供されている機械学習ライブラリは、長期的な運用を目標としてデザインされていない。そのため、高い識別性能を維持するには、通常のソフトウェア開発・運用の知見では不十分である。本レポートの目的は、アメーバブログに提供している機械学習フィルタを例として、長期的に運用可能な機械学習システムを考察することである。 目次 1.はじめに アメブロは,アメーバで最も古く,情報発信手段として多くのユーザに利用されているブログサービスである.2015年2月のデータでは,一日当たり約数十万件のエントリーが投稿されている.一方で,一部の悪意
PagerDutyのOn-callを一時的に自分にアサインするdutymeというツールを書いた 現在のチームではインシデント管理にPagerDutyを使っている.On-callはPrimaryとSecondaryの2人体勢でそれを1週間ごとにローテーションで回している.On-Callにアサインされている場合は夜中であれ日中であれPrimaryにアラートが飛ぶ(Primaryが反応できなければSecondaryにエスカレートされる).そしてアラートを受けたら何かしらの対応を行う. これはうまく回っているが問題もある.業務中(日中)はPrimaryやSecondaryに関係なくチームメンバーはどんどんデプロイしたりProduction環境で作業をしたりする.そしてオペレーションやデプロイ対象のコンポーネントによってはアラートが発生してしまうことがある.つまり作業者に関係なくアラートがPrima
2020/05/26 追記 Docker for Mac の Mutagen-based caching で Volume のパフォーマンスが劇的に改善した Mutagen単独で試してみたことがあって、すごく速くてよかったんですが、 Docker for macに統合されそうな感じになってるんですね。 これは期待。 2017/3/15 追記 先日この問題のissueに対して、 というコメントがつけられ、それに関する というプルリクが 本体にマージされたようです。 まだ詳しく見ていませんが、マウント時に同期方法オプションが指定できるようになり、そのオプションによってキャッシュするレベルを制御して同期を軽くしよう、というような感じになるようでした。 実際にリリース版で使えるのはいつなのかわかりませんが、やはり本体が早くなるのが一番いいのでちょっと期待ですね。 ========== 追記ここまで
最近よく取材や登壇などで「コップに水をためよう」と話しています。どういうことか。 誰もがコップを持っているそのコップには、失敗をすると水が少しずつたまっていきます。コップが溢れるときが成功です。要は、失敗を全くしない人は1ミリも水がたまらないということです。成功するには、コップに水をためる必要がある。 たまに偶然最初から一発当てる人がいます。それが再現性があればその人は「失敗せずに成功できる」天才かもしれませんが、ほとんどの人はそれが偶然であり、再現性がない限りそれは実力ではありません。 たくさん失敗して、コップに水をためよう。 コップに水をためるスピードが速い人、遅い人世の中には、水がたまるスピードが速い人と遅い人がいます。どういうことかというと、同じ失敗から多くを学ぶ人と、何も学ばない人がいるということです。 例えば、新卒の私が大きな予算でマーケティング・キャンペーンをして、大ゴケした
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く