#ssmjp で最近のサーバーレスの話をしました - めもおきば
2/16のssmonline #32にて、「最近のサーバーレスの話」を話してきました。 スライドはこちら： 最近のサーバーレスの話 #ssmjp by @nekoruri おさらい：サーバーレスってなんだっけ？ まずは軽くおさらいからです。 サーバーレスは性質をあらわしているので0／1であてはまるものではないですが、やはり完全従量課金という課金モデルに近づける努力をしているものをそう呼んでいきたいところですね。 最近のサーバーレス開発 サーバーレスといえば、FaaS（AWS LambdaやAzure Functions）で様々なサービスをイベントドリブンでつないでいくアーキテクチャが注目されてきました。「もう古い」はちょっと盛りましたが、単純にFaaSで処理をつなぐのでは、そういったイベントドリブンな「ピタゴラ装置」を管理するのが大変です。 失敗時の再送や、異常データの除外（DLQへの積み
もう「サーバーレスだけどサーバあるじゃん」という話をしたくない - めもおきば
3年ぐらい同じ事を言い続けてるんだけど、そもそもサーバーレスという言葉の由来はソフトウェアアーキテクチャの話*1。 一つのタスクの実行期間を超えて、ファイルシステムやメモリ上の変数などサーバ固有のリソースに依存しないという、12 Factor Appから死ぬほど言われ続けている制約を満たすプログラミングモデルがサーバーレスの本質です。この制約に視点を置くとサーバーレスとしか言いようがない。 これを真面目にやろうとすると、キューやPub/Subによる非同期タスク（イベント駆動）が必要になってきます。これを整理したのがリアクティブシステム、わかりやすく関数という枠にはめたのがAWS LambdaをはじめとするFaaSです。 その一方で、これを満たしたソフトウェアは、AWSなりAzureなりGCPなりクラウド基盤側が勝手にサーバを増やしたり減らしたりできて、完全従量制にできたりメリットがたくさん
パスポートと公開鍵の議論ポイント - めもおきば
www.osstech.co.jp この記事をきっかけに公開鍵暗号やPKIの在り方について議論が盛り上がってるので、ポイントになりそうな話をまとめてみます。 パスポートにおける公開鍵暗号のおさらい 上の記事を読んでください、という感じなのですが、ざっくりまとめると以下の仕組みです。 ・ICカードにアクセスするためのBasic Access Control：いわゆるPINとかに相当します。「パスポート番号 + 生年月日 + パスポートの有効期限」とのことなので、要するにパスポートの顔写真のページを見た人ならば分かる情報です。 ・データの電子署名を確認するPassive Authentication：Basic Access Controlを通ると、券面のデータ及び、そのハッシュ値：SOD(Security Obeject Document)、SODに対する電子署名が取得できます。この電子署名
「通信の最適化」の論点 - めもおきば
論点書き出してみたけど多すぎて超絶カオス。 現状発生している実害 チェックサム比較の失敗(発端) 画質の劣化 exif等メタデータ削除による情報欠損 元ファイルよりサイズが増える 技術的詳細が非公開 「最適化」という単語の是非 オプトインとオプトアウト 送信者(コンテンツ提供者)の同意 自衛のために全HTTPS化することで、かえってトラフィック増える問題 HTTPS化による計算機コスト、ファイル改竄による不具合対応のリスクの負担 サービス内容の意図しない/再現が難しい劣化*1 受信者の財産権の侵害とも言える。 受信者(顧客)の同意 消費者保護観点からより深い内容周知の上での同意が必要では無いか オプトアウトが可能かどうか ISPとしてのサービスが土管であるべきか否か 例えば、可逆圧縮での再圧縮なら良かったのかどうか 携帯キャリアが提供しているのは「インターネット」サービスかどうか iモード
Superfish/eDellRootが危険な理由 - めもおきば
Lenovo製のPCの一部にSuperfishというマルウェアが標準でインストールされていることが確認され、大きな問題となっています。 [2015-11-24追記] DELL製のPCにも、「eDellRoot」とされるSuperfishと同様の問題を持つルート証明書が導入されているようです。 DellのPCに不審なルート証明書、LenovoのSuperfishと同じ問題か - ITmedia エンタープライズ Dude, You Got Dell’d: Publishing Your Privates - Blog - Duo Security Joe Nord personal blog: New Dell computer comes with a eDellRoot trusted root certificate https://t.co/chURwV7eNE eDellRootで
OpenSSLの脆弱性で想定されるリスク - めもおきば
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者（一般ユーザ）の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ
CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば
必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも) SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして
Chef Casual Talks Vol.1で「ChefとCapistranoの境界線」について問題提起してきた #eytokyo - めもおきば
ChefとCapistranoの境界線 (Chef Casual Talks Vol.1) #eytokyo #opschef_ja 大きく分けて二つの話をしました。 Chefを導入する時の「考え方」 Chefのような構成管理ツールは万能でやり方もたくさんある(TMTOWTDI)ので、最初にどういうポリシーで組み立てるかが重要になります。今回「本気で使う」にあたり、以下のようなポリシーを設定しました。 原則サーバ上で作業せず、Chefで環境設定を実装する 公開されたcookbooksを再利用する opscode-cookbooksにあればそれを探す communityやgithubにあるcookbookを使う あきらめの心を持つ 必要ならばopscode-cookbook�sなど既存のcookbookをforkして手を入れる 半日調べて難しそうなことはあきらめる(自前Chef recip
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
