7/29/2016

Gmaneが終了

メーリングリストアーカイブのGmaneが終了するとのこと。現時点で、アクセスしてもCloudFlareのエラーとなるので、停止させた模様。

もし、メーリングリストアーカイブのGmaneを利用しているなら、代替先を探し始めてほしい。Gmane開発者のラース・インゲブリグトセンが木曜日に、10年経ったemail-to-newsゲートウェイの終了を考えていると発表した。しかし、まずはGmaneを意識していない人に、何を行っているかを示す:
いろいろなウェブインタフェースを通じて、あたかもUsenetニュースグループかのようにメーリングリストにアクセスすることが可能である。Gmaneはアーカイブであり、メッセージは決して消去されない(ユーザにより明示的な要求がない限り)。Gmaneはリストに含まれるより前に投稿されたメールの取り込みもサポートしている。
インゲブリグトセンはGmaneのマシンが多数のDDoS攻撃にあっていると語った -- 他の問題に加えて、Gmaneの運用を維持することに時間と努力を掛ける価値があるかどうかを疑問に感じている。彼は次のように書いている:
私は少なくともウェブサイトとしてのGmaneの終了を考えています。おそらく、SMTP-to-NNTPブリッジは続けるでしょう? そうかもしれません? 私はアドレスが戻って来始めた2-3万のメーリングリストを作りたくはありません。しかし、単に届いたメールをすべて/dev/nullに集めてもいいんですが... (NNTPやHTTPインタフェースを持つ)メーリングリストアーカイブが素晴らしいのは、ソフトウェアメンテナが利用可能なことで(誰かが不快なメーリングリストの代わりにきちんとしたコラボレーションツールを使おうと提案する)、「ええ、Gmaneの内容を読んで下さい」と言われることです。私は同世代の人々をがっかりさせた気がしています。
Gmaneの将来は先行きが不透明である。インゲブリグトセンはメールアーカイブを検討するよう提案している。

RFC 7934: ホストアドレスの有効性の提案

ホストに割り当てるIPv6アドレスは複数アドレスを設定することを提案するというRFC標準(RFC7934)。その他、NAT禁止、DHCPv6-PDを推奨。


IPv6アドレスは資源枯渇を心配しなくていいので、一台のホストに複数のアドレスを設定することで、アプリケーションの機能性、シンプルさ、プライバシー、フレキシビリティなどメリットが大きく、NAT無しにインターネットアクセスが可能。

IPv6はインタフェース毎に複数のアドレスをサポートするよう設計されている。今でも、リンクローカル、ステーブルアドレス(EUI-64 [RFC4941]、Opaque-IID [RFC7217])、プライバシーアドレス[RFC4941]、DHCPv6によるアドレスと3つ以上が設定されている。

3. 複数アドレスのメリット

  • プライバシーアドレスで追跡を回避
  • モバイルデバイスは複数のプロセッサを持ち(アプリケーション、ベースバンド)、それぞれが通信をしている
  • テザリング
  • 仮想マシン
  • 464XLATのようなIPv4/IPv6トランスレーション
  • ID-Locatorアドレス
  • 未来のアプリケーション (アプリケーション毎にアドレスを付与)

例としては、

  • 464XLAT: プロバイダ側でPLATを提供する場合、送信元アドレスはプロバイダから提供されるアドレス空間で生成
  • /64共有 (RFC7278): DHCPv6-PD必要なしでテザリングができる。3GPPリリース10以降で可能

4. ホスト毎にアドレス数を制限することの問題

制限するということは、複数要求できなくなる機能を入れることを暗示していおり、次の欠点を持ってしまう。

  • プロビジョニング(アドレス割当)で人手が入ることとなり、時間が掛かる
  • プロビジョニングが成功・不成功になるまで、アプリが使えるかどうか分からない
  • プロビジョニング運用の複雑さが増す
  • プロビジョニング用サーバの負荷が増す

アドレスを制限する理由:

  • ハードウェアの制限 → 時間とともに緩む
  • ビジネスモデル(課金) → ユーザはNATを使ってしまうので、収入が入らず、むしろ運用コストが増す
  • IPv4との運用の一致性

5. NATを使って制限を打開すること

  • NATは障害点になる
  • アプリの複雑さが増す
  • モバイルデバイスにとってバッテリー消費が増す(keepaliveが必要)
  • IABのガイダンスではIPv6 NATのデプロイをすべきではない
  • しかし、現実にはNAT66の実装は行われている: Linux(2012年)、ポピュラーなハイパーバイザ

6. 複数のアドレスを提供する選択肢

7. 必要なアドレス数

  • プロバイシーアドレス: 7
  • モバイルデバイスはアップリンクを8クライアントアドレスで共有
  • クライアントは複数アドレスを持ち、VMを動かしている
  • 464XLATはそれぞれ別に必要
  • ベースバンドチップは別アドレス

これらの機能を同時に使うことを考えると、20程度が同時に必要となる。

8. 推奨

  • 各ホスト毎に複数のIPv6アドレスを提供する
  • ホストに一つのIPv6アドレスだけというのは推奨しない
  • 明示的なリクエストを要求せずに新しいアドレスを利用可能にする(SLAACまたは専用の/64)
  • ステートフルなアドレスの割当は今は承諾するが、アドレス数を制限してしまう可能性がある

9. 運用の考慮

9.1 ホストの追跡

  • ルータのネイバーテーブルをモニターする
  • /64専用のSLAAC、DHCPv6-PDのアドレスは容易に追跡可能
  • DHCPv6サーバのログで追跡するのはお勧めしない

9.2 アドレス空間

  • /48は192.168.0.0/16に相当(ホストは/64を受け取れる)
  • /40は10.0.0.0/8に相当

現状のRIRのポリシー(/48を簡単にもらえる)なら、ホスト毎に/64を割り振って問題ない。

9.3 IPルーティングによるリンク層のスケーラビリティ問題の対処

リンク上のIPv6アドレス数がネットワークのインフラに影響を与え、L2アドレスなりすましでの資源枯渇攻撃をやめさせる必要がある。ホスト毎に/64を割り当てることで対応出来る。

7/28/2016

トランプ氏、クリントン氏の行方不明のメールを探すようロシアに呼びかけ

トランプ氏がDNCへのハッキングを行ったと疑われているロシアに向け、ヒラリー・クリントンの削除された3万通のメールを探し出すよう呼びかけた(Slashdot)。

水曜日の記者会見に参加したレポーターによると、共和党大統領候補のドナルド・トランプ氏は、ヒラリー・クリントン氏が国務長官として在職のメールをハックするため、米国への他のサイバー攻撃に乗り出すようDNCのメールの最近のリークに関与したと言われるロシアのハッカーに公然と呼び掛けた(他の情報源: NYTimesQuartzMotherJones)。トランプ氏は「ロシア、聞いているなら、君たちなら行方不明の3万通のメールを探すことができると思う。おそらく我々プレスの見返りが得られると思う」と語った。

クリントン氏は国務長官を務めていた間に個人のメールアドレスを使っていたことに対する調査を受けた。国務省への彼女の在職した年の間に、すべての公務文書をFBIに引渡し後、クリントン氏は、娘の結婚のような個人的な事柄に関連するメールの半数を削除したと昨年の記者会見で明かした。ロレッタ・リンチ法務長官はクリントン氏に対して刑事罰を追求しないことを最終的に決めた更新: ここにトランプ氏がそう語るビデオがある。

BoingboingTechCrunch

7/27/2016

民主党全国委員会へのロシアのハック

民主党全国委員会(DNC)の幹部のメールが流出した一件にロシアが関与しているという話題を、シュナイアー氏が取り上げている。

驚いたことに、圧倒的多数の証拠はDNC漏洩の原因としてロシアを指している。私は証拠の簡単にまとめるつもりだったが、トーマス・リード(Thomas Rid)教授が素晴らしい仕事をした。その多くは、クラウドストライク社による6月のフォレンジック解析をベースにしており、私はここにまとめた。さらに詳しい解析はここにある。

ジャック・ゴールドスミスは政治的な影響を考察する

FBIが調査している。NSAがこの攻撃に追加の諜報活動をしていることを期待するのは無理はない。同様に彼らはソニーに対する北朝鮮の攻撃でもどの程度関与していたのか。

BoingboingSlashdot

メリッサ・メイヤー、Yahooを去ると5500万ドル獲得

もしも彼女がYahooとの契約を終了させるなら、素晴らしい年俸諸特典を得ることになる。Yahooを立て直せずに高い賞与を得るわけか... (Boingboing)

現在自身を売却しようとしている追い詰められたオンラインニュースサイトのCEOは、市場が閉まった金曜日後に規制当局に提出された書類によると、万が一彼女が理由もなく契約を終了する場合、5490万ドルの退職金が得られる。書類によると、メイヤーの配当は企業の売却を含む「支配権の変更」も絡んでいる。

メイヤー氏の配当は300万ドルの現金による退職金、医療補助を続けるための26,324ドル、再就職あっせんのための15,000ドル、そして...いい加減にしろ... 約5200万ドルの価値がある制限付きストックオプション。

Hacker News

更新 (2016.7.28): フォーチューンによると、メイヤー氏が得る金額は1億ドル以上($122,578,795)とのこと。

更新 (2017.4.26): 2017-06-08にYahoo株主はベライゾンに売却するかを決定する。株主に送付された文書には、株価は月曜日の48.15ドルに基づくそうで、メイヤー氏が持つ株式の総額は1億8600万ドルになるとのこと。売却が成立すれば彼女には2億ドルが手に入る。SlashdotHacker News

エンド・オブ・マイクロサービス

エンド・オブ・マイクロサービスと題するエッセイ。タイトルからするとミスリードだよなぁ。「マイクロサービスの先」という意味かな。

信頼性があってスケーラブルな生産システムが他のソフトウェアを書くのと同じくらい簡単にできるようになった未来からの投稿。未来がどのようになっているかを知るために読んでほしい。

2016年頃、人々はマイクロサービスについて数多くを書いたが、それは1996年頃に情報スーパーハイウェイについていかに数多く書いたようなものだった。ちょうど情報スーパーハイウェイという表現は徐々に消え、人々はインターネットを構築することに立ち返った。サービスがスケーラブルなソフトウェアシステムを構築する標準的な方法になるにつれ、マイクロサービスのマイクロという部分が落とされた。名前の意に反し、我々は双方の言い回しを、どのように人々がそれについて考えたかの転換を示するのに使った(そして取り残された)。サービス指向アーキテクチャを使うことは、開発者がサービス間の接続にフォーカスすることを意味し、より良いソフトウェアをより早く構築することを可能にした。

Rise fall information superhighway

情報スーパーハイウェイの盛衰(ソース)

2016年以後、開発者は一度に一つのサービスに重点的に取り組むことによって、より生産的になった。サービスとは何? 大雑把に、シンプルに定義でき、独立してデプロイされるソフトウェアの最小の役立つ固まりである。通知サービス、ログインサービスあるいは、永続性のあるKey-Valueストレージサービスを考えてみてほしい。頑丈なサービスは一つだけで、うまくこなす。開発者は仮想マシンあるいは他の低レベルインフラについて心配する必要がなくなったため、速く変化している: サービスは抽象度を上げている (もう一つのバズワード: しばらくの間、サーバーレスコンピューティングと呼ばれた)。そして、サービス間の接続は明確だったため、開発者は総じてアプリケーションについての考えから解放され、むしろ自身の機能やそれが依存するサービスに集中できる。

ずっと昔、多くの組織は「一つのバイナリを10の小さなバイナリに分解する」するつもりで、マイクロサービスアーキテクチャへの移行を考えた。彼らが見つけたものは、10回以上繰り返すだけという同じ古い問題を持っていたことだった。そのうち、彼らは頑丈なアプリケーションを作ることは、単にモノリスを小さな固まりに分解するという問題だけではない、むしろ、これらの固まりの間の接続を理解することだと気付いた。これは正しい疑問を尋ね始めた頃だった: 私のサービスが依存するサービスは何だ? 依存関係が効果がない場合、何が起きるのか? どんなサービスが私のサービスにRPCを作るのか? 私が期待するRPCはどのくらい必要か? これらの疑問に答えることは新しいツール群や新しい見方を要求した。

ツール、ツール、ツール

サービス指向アーキテクチャを作ることは独立して相互接続されるサービスの性質を調整するための新しいツールキットなしには不可能だろう。ツールはサービスをプログラムで表現し、API境界とサービス間の関係を定義する。それらは異なるサービスの相互作用を管理する規約を効果的に定義する。これらのツールはマニュアル、サービスのテストを手助けし、分散アプリケーションの構築と共に多くのひな形を生成する。

もう一つの重要なツールはデプロイを手助けし、サービスをまとめることだ: そのサービスは、高レベルのサービスを彼らが消費する基本リソースにマッピングするスケジューラ(そして、適切にそれらをスケールする)、彼らが行く必要のある場所を得るリクエストを確認するためのサービス発見やロードバランサである。

結局、アプリケーションがデプロイされると、第3のツールは開発者がどのようにサービス指向アプリケーションが振る舞い、問題が起きた場所や理由を探し出すのを助けるかを理解するのを手助けする。マイクロサービスの初期に遡ると、開発者はモノリシックなアプリケーションを持つことに慣れていた頃の多くの視野を失った。突然、もはやログファイルをgrepしたり、rootが引き起こしたことを発見するだけではなくなった: 今では、答えは数百のノード上のログファイルを分解され、数千の他のリクエストに綴じ込まれた。分散アプリケーションの挙動が本当に理解されたのは、マルチプロセスのトレーシングの出現、集約クリティカルパスの解析、そして高度なフォルトインジェクションだけだった。

これらのツールの多くは2016年時点で存在していたが、エコシステムはまだ開花していたなかった。幾つかの標準はあったが、新しいツールは意味のある投資が要求され、既存のツールは一緒にはうまく動作しなかった。

新しいアプローチ

ある程度このツールキットが理由で、サービスは日々、開発者ごとに考え方がある。しかし、ソフトウェアを作る中で、開発者がサービスについて初めて考え始めた時に、真の変革は起きた。テスト駆動型開発と同じように開発者はプログラムを書く前からテストすることを考え始めたことを意味した。サービス駆動型開発は、サービス依存性、パフォーマンス・インストゥルメンツ、RPCコンテキストが最初の関心事になった(そして、単に問題がその後に取り繕われないだけでなく)。

全体として、サービス(マイクロかそうでもないものでも)は望ましいことである。(我々はもはやマイクロサービスと呼ぶ必要ななく、思い返せば、重要なのはサービスのサイズでは決してなかった: それはつながりであって、それらの間の結び付きだ)。サービスは機能の周りにソフトウェア開発の話し合いを再度中心にし、開発者がより速く作業をすること、ユーザに価値を届けるという真に重要なことを実行するためにはより自由であることを可能にした。

Hacker News

7/24/2016

ウェブ開発者のための実践的セキュリティガイド

今の所、セキュリティチェックリストのみ

認証系システム (サインアップ/サインイン/2ファクタ/パスワードリセット)

  • どこでもHTTPSを使っている
  • Bcryptを使ってパスワードハッシュを保存している(ソルト不要 - Bcryptが代わりにやってくれる)
  • ログアウト後にセッション識別子を完全に削除する(もしくは提案する)
  • パスワードリセットで全てのアクティブセッションを完全に削除する
  • OAuth2のstateパラメータを持つに限る
  • ログイン成功後にリダイレクトしない、あるいはそれ以外はリダイレクトを仲介する
  • サインアップ/ログイン入力を解析する際、javascript://、data://、CRLF文字をサニタイズする
  • クッキーにhttpOnly属性を安全のために設定する
  • モバイルOTPベースの検証で、OTP生成あるいはOTP再送のAPIが呼ばれる際、応答にOTPを送り返さない
  • 個々のユーザへのログイン、OTP検証、OTP再送、OTP生成APIの回数制限をする。累乗でスピードを落とす、あるいは/それに加えてチャレンジベースのキャプチャのようなものを使う
  • メールのリンクあるいはSMSでリセットパスワードトークンのランダム性をチェックする
  • リセットパスワードトークンに適正な期限を設定する
  • 成功裏に使われた後、リセットトークンを失効する

ユーザデータと承認

  • カートや履歴のようなリソースへのアクセスはセッションIDをそのリソースが使ってログインユーザの所有であることを確認すべき
  • 連続する反復可能なリソースIDは避けるべき。/user/37153/ordersの代わりに/me/ordersを使う。
  • メールや電話番号の修正機能はアカウントの持ち主への確認メールを伴うべき
  • いかなるアップロード機能もユーザによるファイル名をサニタイズすべき。また、セキュリティはさておき一般的な理由で、S3(やlambdaを使った後処理)のようなものへのアップロードやサーバがプログラムを実行できないようにする
  • プロフィール写真のアップロードは使っていなくてもEXIFタグを全てサニタイズすべき
  • ユーザIDや他のIDに、整数の代わりにRFC準拠のUUIDを使う。Github上であなたが使っているプログラミング言語での実装を見つけることができる
  • JWT (JSON Web Token)は素晴らしい。シングルページアプリ/APIに必要であれば使って欲しい

Android/iOSアプリ

  • 支払いゲートウェイのソルトはハードコードすべきではない
  • サードパーティ製のSDKのsecret/auth tokenはハードコードすべきではない
  • サーバ間で実行することを目的としたAPI呼び出しはアプリから実行すべきではない
  • Andoridで、パーミッションの全許可は注意深く審査すべき
  • 証明書ピンニング(ピン留め)は大いに推奨される

セキュリティヘッダと設定

  • XSSやデータインジェクション攻撃を緩和するためCSPヘッダを加える。これは重要
  • クロスサイトリクエストフォージェリを防ぐためCSRFヘッダを加える。クッキーにSameSite属性も追加
  • SSLストリッピング攻撃を防ぐためHSTSを加える
  • HSTSプリロードリストにあなたのドメインを加える
  • クリックジャックから守るためX-Frame-Optionsを加える
  • XSS攻撃を緩和するためX-XSS-Protectionヘッダを加える
  • スパムやフィッシング攻撃を緩和するため、SPFレコードをDNSレコードに加える
  • サードパーティCDNからJavaScriptライブラリをロードするなら、Subresource Integrityチェックを加える
  • ランダムなCSRFトークンを使って、HTTP POSTとしてビジネスロジックAPIを見せる。初期リクエストアップグレードフェーズで例えばHTTP越しにCSRFトークンを晒さない
  • GETリクエストパラメータの中で大切なデータやトークンを使わない。サーバログあるいはマシン/スタックの処理の公開は次々にユーザデータを露出するだろう

入力のサニタイズ

  • XSSを防ぐため、ユーザにさらされるすべてのユーザの入力あるいは入力パラメータをサニタイズする
  • SQLインジェクションを防ぐため、ユーザにさらされるすべてのユーザの入力あるいは入力パラメータをサニタイズする
  • CSVインポートのような機能を直接使うならユーザ入力をサニタイズする
  • coolcorp.io/usernameのようなurlパターンを使う場合のプロフィール名としてrobots.txtのような特別な場合にユーザ入力をサニタイズする
  • どんなに小さなオブジェクトであろうと、文字列連結によってJSONを手渡したり作成しない。ライブラリあるいはフレームワークを定義するプログラミング言語を使う
  • SSRFを避けるため何らかのURLを取り込む入力をサニタイズする
  • ユーザに表示する前に出力をサニタイズする

運用

  • 未熟で経験不足なら、あなたのプログラムを実行するのにAWSのelasticbeanstalkあるいはPaaSを使って評価する
  • クラウドのVMを作成するのに、ちゃんとしたプロビジョニングスクリプトを使う
  • 不要なポートをオープンしていないかマシンをチェックする
  • データベース、特に、MongoDBとRedisのパスワード無し/デフォルトパスワードをチェックする
  • マシンへのアクセスにSSHを使い、パスワードは設定しない
  • HeartbleedやShellshockのようなゼロデイ脆弱性に基づいて、タイムリーに更新をインストールする
  • HTTPS/TLS 1.2を使うためのサーバ設定を修正し、他のすべてのスキームを無効化する(トレードオフが望ましい)
  • デバッグモードを有効にしておかない。フレームワークの中で、デバッグモードは本格的なREPL、あるいはシェルへのアクセスを与え、エラーメッセージのスタックトレースの中の重要なデータをさらしてしまう
  • 悪人とDDOSを覚悟する - CloudFlareを使う
  • システムやログのモニタを設定する (New Relicを使う、あるいはそのような何か)
  • エンタープライズな顧客の開発なら、コンプライアンス要求を守る。AWS S3なら、データの暗号化の機能を使うことを考える。AWS EC2を使うなら、ボリューム全体を暗号化する機能を使うことを考える(今はブート用のボリュームも暗号化できる)

ピープル

  • 脆弱性を報告するためのメール(例: security@coolcorp.io)やセキュリティ調査員のページを設定する
  • あなたが作った内容によって、ユーザデータベースへのアクセスを制限する
  • バグの報告者に礼を尽くす
  • セキュアなプログラミング能力を持つ仲間の開発者によるコードレビューを受ける(多くの人に見てもらう)
  • ハッキングやデータ侵害の場合、以前のアクセスログをチェックし、パスワードの変更を要求する。あなたの取り組み如何に関わらず、外部機関による監査を求めてもよい
  • ソーシャルプラットフォームやGoogle検索でのあなたの組織についての話を調べるためにNetflixのScumblrを設定する

Hacker News

7/22/2016

共和党員は「ゲーム・オブ・スローンズ」がお嫌い

E-Scoreが民主党員と共和党員に好きなドラマを尋ねた。民主党員が一番好きだった「ゲーム・オブ・スローンズ」は共和党員の中ではTOP 10に入っていない。特徴としては、民主党員は人種的多様性があるドラマを、共和党員は善悪系のドラマがお好きとのこと。


# 民主党員 共和党員
1 ゲーム・オブ・スローンズ (HBO) スーパーナチュラル (CW)
2 The Haves and the Have Nots (OWN) ウォーキング・デッド (AMC)
3 スーパーナチュラル (CW) スコーピオン (CBC)
4 ビッグ・バン・セオリー (CBS) アロー (CW)
5 SUITS/スーツ (USA) フラッシュ (CW)
6 ウォーキング・デッド (AMC) ビッグ・バン・セオリー (CBS)
7 殺人を無罪にする方法 (ABC) NCIS (CBS)
8 ドクター・フー (BBC) ブルーブラッド 〜NYPD家族の絆〜 (CBS)
9 Empire 成功の代償 (FOX) グリム (NBC)
10 ナッシュビル (ABC) Last Man Standing (ABC)

Boing boingmic

共和党党大会でローラ・イングラハムがナチス式敬礼

アメリカで人気の女性保守派政治トークショーホストのローラ・イングラハム。クリーブランドの共和党党大会の演説を終えた際のナチス式敬礼(ローマ式敬礼)に非難が上がっている。

Ingraham21n 1 web

Boing boing

7/21/2016

アクティブなIPv4アドレススペースの新しい視点

CDN(アカマイ)の膨大なアクセスログを使ってインターネットのアクティビティを分析した論文。論文の内容は、IETF 96で発表されている。IPv4アドレスのアクティビティは2014年あたりから成長が止まっている。

この研究で、我々は1日に3兆近くのHTTPリクエストを扱う巨大な商用CDNのサーバログを頼りに一つ一つのIPアドレスの粒度でインターネット全体のアクティビティを捕らえることを可能にする技術と分析について報告する。2015年全体にわたって、これらのログはかつてないほど多くの測定で最近の見積もりと一致する12億のユニークなIPv4アドレスを含むクライアントのアクティビティを記録した。毎月のクライアントIPv4アドレス数は毎年コンスタントな成長を見せていたが、2014年からIPv4数は成長が止まったと同時にIPv6の数が成長している。従って、複雑な進展を特徴とする時代に入ったとみており、アクティブなIPv4アドレスの単一の一覧は全体としてのインターネットの最近の成長を特徴づけるのにほとんど役に立たない。
この観測を考慮に入れ、我々はグローバルなIPv4アドレスのアクティビティの調査の中で新しい視点を考察する。我々の解析はアクティブなIPv4アドレスで暗示的な揺れ(チャーン/churn)が見える: 1年の間で一連のアクティブなIPv4アドレスの25パーセントが変化している。第二に、プレフィックスのアクティブなアドレスを見ると、ネットワークの再構築、とりわけいくつかのアドレス割当においてユーザの行動に起因すると考えられるアクティビティパターンを確認できる。第三に、トラフィックボリュームの測定でアドレスの利用の時空間的測定と関連するホスト数のサンプルベースの見積もりを組み合わせると、いくつかの地域では未利用の経験的観測や完全な利用あるいは涸渇などをを含め、世界的なIPv4アドレスのアクティビティでこれまでにない全体像を提示する。

Hacker News

7/20/2016

メラニア・トランプ氏、ミシェル・オバマ氏の演説盗用疑惑

クリーブランドで行なわれている共和党の党大会初日、ドナルド・トランプ氏の妻でファーストレディー候補:-)であるメラニア・トランプ氏の演説の一節が、2008年民主党の党大会でミシェル・オバマ氏が行った演説の文面を盗用していたとニュースになった。メラニアの演説は当初は高評価だったが、盗用(パクリ)が分かると、ツイッター上では#FamousMelaniaTrumpQuotesのハッシュタグ付きで盛り上がった。スピーチライターが原稿を書いたのかと思ったら、メラニア氏はNBCテレビに対して、「できるだけ人の手を借りずに自分で書いた」と話していた。

BoingboingCNN(J)

7/18/2016

Junos、偽のSSL証明書を有効と判断する脆弱性

Junosに詐称された信頼できる発行者(Issuer)のコモンネーム(CN)を持つ自己証明書を有効と受け入れてしまう脆弱性が見つかったとのこと。セキュリティアドバイザリ(JSA10755)が公表されている。解決方法は修正されたJunosへのバージョンアップだが、相手先のIKE IDとしての識別名(DN)のみを受け付けるようPKI-VPNトンネルを設定するワークアラウンドがある。

Junos OSは証明書の検証にPKIdが動いています。相手デバイスがJunosの中に登録されている有効なCA証明書の一つに一致する発行者名を持つエンドエンティティ証明書として自己証明書を提示すると、相手の証明書の有効性がスキップされ、相手の証明書が有効として処理されます。これは攻撃者に特別なやり方で巧妙に作られた自己証明書を生成することを許してしまうかもしれません。

この問題はIKE/IPsecを使う証明書にのみ影響します。他の公開鍵ベースの認証はこの脆弱性による影響はありません。

Juniper SIRTはこの脆弱性のいかなる悪意のある攻撃コードを承知していません。

この問題による影響を受けるのは、Juniper Networks社の製品あるいはプラットフォーム以外にありません。

この問題はCVE-2016-1280にアサインされます。

"特別なやり方で巧妙に作られた (specially crafted)"といっても、名前を*.juniper.netのようにするだけと思われる。

ars technicaSlashdotHacker News

7/17/2016

Swift 4の議論は8月1日以降に開始

AppleのTed Kremenekから、Swift 3の最終段階とSwift 4の議論開始のアナウンスがあった。要点は次の通り。

  • 7月27日がSwift 3に対する計画されたソース変更を受け取る最終日である。
  • その日に、Swift 3に関して承認されるが実装されない提案 (ソース変更を伴う提案を含む)がありそうだ。その日にSwift 3のコンテキストの中で実装されない提案の行方や将来のSwiftのリリースについてオープンな議論を行う。
  • 8月1日以降に、Swift 4についての議論を開始するだろう。おそらく、この議論の一部はSwift 3で保留された重要な仕事に左右されるだろう。Swift 4でのバイナリの安定性を達成する目標も同様である。それまで、しかし、議論はSwift 3で集中したままにすべきだ。
  • Swift 3に関するソース変更を得る最新の計画された日と、Swift 4について話し始める時との間に、数日間の意図的な間があることに注意してほしい。そのアイデアは最終的にSwift 3になるものを評価するため、コミュニティに時間を与えるためである。
  • Swift 3に関する開発の最終的な分岐計画は将来決定する。しかし、最終的な収束分岐はその前後あるいはその直後に、masterからカットされることになるだろう。その一部は、7月27日にSwift 3の残存する実装されない提案を対処する方法に議論が及ぶ。
  • Swift 3の最終的なリリース日は未決定だが、基本的に7月27日後で、その合意はSwift 3は完全な合意であり、開発中のものではない。

どこまでマーク・アンドリーセンはインターネットを発明したのか?

「Web=インターネット」ではないと思うが、マーク・アンドリーセンの業績は今日のインターネットの発展に欠かせないものであることは間違いない。

どこまでマーク・アンドリーセンはインターネットの発明したのか?

ザック・ブルーム
新しいクライアントのベータテストに興味はあったら、下記にメールを送って下さい: beta@mcom.com ありがとう、マーク — マーク・アンドリーセン、1994年のMosaic(後のNetscape)の公表

先週のマーク・アンドリーセンの誕生日を祝う中、我々はインターネットへの彼の驚くべき重要な貢献をざっと眺めることは素晴らしいと思った。いずれの仕事も彼がベンチャー投資家になるずっと前の出来事だ。彼はNCSAで働く普通のエンジニアだった、その後Netscapeの創立者になった。彼の決断を振り返ると、Netscapeの運営がウェブを定義することになった。

イメージタグ

...現在のところ、私は概してSGMLへの対応は完全に時間の無駄だし、我々が受け継いでまだ支えているSGMLの負担による面倒を抱えていなければ、今はさらに前に進んでいただろうと思います。99.99パーセントの人々はリッチドキュメントをオンラインで書くことを、見たままで管理したいと望んでいるし、結局のところセマンティックなマークアップあるいは文書構造と体裁の間の区別についての関心がないのです。他の0.01パーセントはキーボード・モニター・マウスの概念全体にまだ取り組んでいるところなのです。 — マーク・アンドリーセン、1993年

マーク・アンドリーセンは<IMG>タグを発明した。彼の関与の前に、もしもHTMLドキュメントに画像を含めたいと思ったら、それをリンクさせるしかない。ユーザはリンクをたどる時、画像は選択した画像リーダーの中でオープンされる。このモデルは、コンテンツはリンクと結合されるべきという考え「ハイパーリンク」の一般的な理論に従っていた。

しかし、マーク・アンドリーセンはユーザがいて、彼らは埋め込み画像を欲していた。

私は次の新しいオプショナルHTMLタグを提案したいのです。 IMG 必要な引数はSRC="url"です。 これはブラウザがネットワーク越しにダウンロードするビットマップあるいはPixmapファイルの名前で、画像として解釈され、タグのある場所でテキストの中に埋め込まれます。 例えば、 <IMG SRC="file://foobar.com/foo/bar/blargh.xbm"> (閉じるタグはありません、これはスタンドアローンタグです) このタグは他の何かのようなアンカーの中に埋め込むことができます。それが起こると、普通のテキストアンカーのようにアクティベーションに反応するアイコンになります。 — マーク・アンドリーセン、1993年

リンクの中に埋め込まれるべき外部リソースを指定する代わりの別の提案(まさにティム・バーナーズ=リーによる):

<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>

そのソリューションは確かにハイパーメディアの理論的なセマンティックには、より協調的だが、問題を解決していない。マークは<img>の実装を推進した。

URLクエリ形式の創作

マーク・アンドリーセンはURLクエリ形式(?a=3&b=2)を開発した。

彼の関与の前、クエリ文字列と同じ文字列は検索にのみに利用されていた。もし、ページに<ISINDEX>タグを含んでいたら、ブラウザはページに検索欄を加える。検索はページのURLにクエリを加えることによって実現され、新しいリクエストを作る:

?dog+shampoo

しかし、一般的な目的フォームに使う(あるいは作る)方法が無かった。これはアンドリーセンが提案したものだ:

こちらはどうでしょう? クエリをサブミットする現在のクエリ・シンタックスを続けてみてはどうでしょうか? それはクエリを「url?query」で表し、多少似ていますが: name=value&name=value&name=value 「=」と「&」文字は予約文字として使われます(nameあるいはvalueにある場合、%xxでエスケープします)。

お分かりのように、これはまさに今日使うクエリのシンタックス形式である。

(今週末クエリ形式の歴史の投稿を行うので、ページの最後で購読すれば、それが公表された時に通知されるます)

EmacsのHTMLシンタックス強調表示

テキストエディタEmacsでHTMLを書いているなら、シンタックスの強調表示はマーク・アンドリーセン自身が作成したモードだとわかるだろう。

1992年にwww-talkメーリングリストにそのようなモードが存在するかを尋ねる最初の彼の投稿があった。

どなたかEmacsでHTMLファイルを作成するためにコードを書いている人はいますか? 私はハックしたので、興味があればお知らせ下さい。 マーク

今でもまだEmacsソースコードの中に彼の貢献を見ることができる。

彼が関わったNetscapeの成果

SSL

とりわけダイアルアップ時代に、インターネット接続は全く安全ではなかった。電話線を盗聴したいと考える人があなたが送受するすべてを読むことができた。これはウェブページでクレジットカード番号やパスワードを送るにはいい環境とは言えない。

アンドリーセンの指導のもと、キップ・ヒックマンはNetscapeで働いた間にSSLを開発した。アンドリーセンはwww-talkメーリングリストへ1994年にそのリリースを自分自身で公表した

最初SSLリリースは大きな欠陥を抱えていたため、Netscapeは実際にはv2.0までSSLをリリースしなかった。そして、1996年にリリースされたバージョン3.0まで安全ではなかった。 インターネット上で安全に通信する能力はインターネットビジネスのようなものが可能になる重要なステップだったことに疑いの余地はなかった。

JavaScript

マーク・アンドリーセンは常にウェブブラウザでプログラムを実行することについて以前からそれほど楽観的ではなかった。

ブラウザがプログラムを実行することはとても恐ろしいです。サーバは一般にuseridは'nobody'として実行します(あるいは実行すべき、しない理由はありません)。それ自体はほとんど何も被害を引き起こしません。とにかく、サーバのプログラマは、ハイパーリンクを無作為にクリックするクライアントユーザよりは、何が起こるか、何が起こりうるのかについての多くの知識を持っています。私はクライアント側の処理が安全だと考える理由があるとは思いません。

アンドリーセンはブラウザでSchemeを実行させるという約束を基にブレンダン・アイクを雇うことができた。企業プロジェクトではよくあることだが、これはもう少しとっつきやすい何かに速やかに再構成された。アイクの言葉で、

推進力は少なくともSunのビル・ジョイと共にマーク・アンドリーセンと私自身のそれぞれの信念でした。それは素人や初心者によって簡単に利用出来るプログラミング言語で、ウェブページのマークアップの一部としてソースコードの中に直接書き込むことができるスクリプト言語がHTMLには必要だということです。我々は例えば、画像、プラグイン、Javaアプレットのような構成要素からウェブコンテンツを作成するウェブデザイナやパートタイムプログラマにとっての「グルー言語」を提供することを意図していました。我々はJavaを高給プログラマによって使われる「コンポーネント言語」、JSを使ってコンポーネントを組み立て、相互作用を自動化するのがグループログラマやウェブデザイナだとみていました。

最初のインタープリタを作成するのに10日、DOMを作成するのに約6か月要した。

マーク・アンドリーセンは最初、JavaScriptを「Mocha」と名付けた。SunとのJavaの商標権のランセンス合意後に(Sunの創立者ビル・ジョイはウェブの開拓者で彼自身が支持者だった)、急成長するJavaと新しい言語を結びつけた名前にすぐに変わった。これがその後数十年にわたって経験不足のプログラマを混乱させることとなった。

対立 (The Divide)

私の考えでは、ウェブの創作に打ち込む人には二つのタイプの人がいる。夢想家(アイデアリスト)はまず物事を始めた。ハイパーリンクを発明したダグラス・エンゲルバーグやインターネットでそれを実現したティム・バーナーズ=リーのような人々である。基盤を作り上げた後、夢想家は全ての人が未来のビジョンに奥深く分け入って行くための標準を作ろうと奮闘した。彼らはURNRDF、そしておぞましいXHTMLのようなほとんど誰も使わないツールを作りあげるのに時間を使った。

ウェブはハイパーメディアの実験としてみていないのはマーク・アンドリーセンのようなプラグマティスト(現実主義者)で、人々が強力なものを作り、今日の現実問題を解決する手段としてみていた。その中で、彼はハイパーメディアのビジョンとあまり協調しない多くのことを作り上げ、統一規格のようなものや開発者にとって、とてつもなく大きな欲求不満を引き起こした。しかし、実際に採用された方法でウェブ上でより多くのことができる可能性を作り上げた。

RDFのようなものが本当にうまくいったなら、インターネットがどのようなものになっていたかは全くわからない。私の考えでは、ウェブは夢想家なしには決して存在しなかっただろう。しかし、プラグマティストなしにウェブ上でこれを読むこともできなかっただろう。


1994年にウェブの未来を議論しているアンドリーセンのビデオがある。

7/14/2016

BGP ADD-PATHがRFC標準化

BGPで複数パス(バックアップパス)を広報するケーパビリティADD-PATHがようやくRFC 7911として標準化された(Daniel Waltonの最初のドラフトが出たのは何と2002年5月のことだ)。BGP ADD-PATHを使って経路を複数AS内に持たせておくことで、外部ASへの自経路のWITHDRAWを防ぐことができる(最適経路のみだと経路が消えてしまうため、収束に時間がかかる)。同一プレフィックス(NLRI)の識別に、Path Identifier(4 octets)が付加される(0から割り当てる実装が多いようだ)。どのような場面で使うかだが、自AS内に複数パスを保持させるためRR/IBGPで用いられるものだと思うが、そのあたりはベストプラクティスのIETFドラフトがある。時間ができたら、VIRLでテストしてみたい。

そういえば、いろいろなパケットのキャプチャ、チートシート、ツール情報を集めているウェブページ(PacketLife.net)がある。BGP関係のキャプチャーはここにあり、ADD-PATHも掲載されている。

7/12/2016

デービッド・キャメロン首相の白鳥の歌

明日辞任することになったデービッド・キャメロン首相、辞任発表後にマイクがオンになっていることに気付かず、「Do doooo, do doo」とハミングをしながらダウニング街10番地へ戻っていった。その後、部屋に入ると少し間をおいて、どっしりと「Right」と加えた(Boingboing)。まさに彼の白鳥の歌になったとのこと。Boingboingが着信音にしてくれた。

オープンソースのiOSアプリリスト

GithubにオープンソースのiOSアプリが489あるとのこと。アプリ開発の参考になるだろう。ホワイトハウスの公式アプリがオープンソースだったとは...

Hacker News

ネクストエコノミー企業に期待する6つのこと

造語作りの名人ティム・オーライリーは昨年あたりからUberやAirbnbのような既存業界に対して破壊的なビジネスを展開するも、規制当局から嫌われる企業・サービスをWTF(なんてこった)エコノミーと呼び、誰もがハッピーになれるビジネス(ネクストエコノミー)への転換を説いている。年初にネクストエコノミーに期待する6つのことと題するエッセイを書いている。

AI、オンデマンド、ロボット工学と多くのバズ(buzz)があり、人手による仕事の将来に関わっている。私はマーケットの現状を「WTFエコノミー」、将来望まれる状態を「ネクストエコノミー」と表現した(だから、最新のイベントの名前は「ネクストエコノミー・サミット」となっている)。

しかし、まさにネクストエコノミー企業たらしめるものは何だろう? どのような場合でもそうだが、テクノロジーの次の進化の特徴を見せている多くの企業がある。しかし、いくつかの企業は他よりもっと明確に本質・原理(principles)が明らかになっている。例えば、全ての企業は今ビッグデータや予測解析(predictive analytics)を生かす方法を学習している。15年前はGoogleがこのトレンドの最高のシリコンバレーの手本だった。UberやLyftは同じ理由で私が今書いているものに取り上げている。それは、彼らは現世代のシリコンバレー企業の中で最も重要とは限らないが、期待する重要なトレンドの最たる例であるためだ。

それでは、私がネクストエコノミー企業を評価する際、何を期待しているのでしょうか?

1. ネットワークに可能性を与えるプラットフォームである

Uber、Lyft、Airbnbのような企業は、かつてGoogle、Youtube、Facebook、Twitterやその仲間を我々にもたらした欠かさせないインターネット物語を作っている。しかし、今回は物理的な世界に起こっている。

2. 単に働く人たちを置き換えるだけでなく拡張する

UberあるいはLyftのドライバーはオーグメントワーカー(拡張された働き手)*で、スマートフォンのシックスセンス無しに不可能なことを行っている。UberあるいはLyftのアプリはリアルタイムに、密集市街地という藁の中から針のような乗客を探す。Googleマップは事前訓練無しにどんな住所へも簡単にナビゲートすることを可能にする。Wazeは運転経験がなくても渋滞を避け、最適なルートを探すのを手助けする。オーグメントワーカーは、デバイスとアプリによってスキルを持たない幅広い人々でも以前は高いスキルが必要だった仕事が可能であることを示している。

* オンデマンド労働と言ったりするようだ

3. 素晴らしいユーザ体験を作っている

Appleがショールームを完全に考え直すためにどのようにスマートフォンの機能を使っているか、あるいはどのようにUberがタクシーを呼ぶ体験を完全に転換したかについて考えてみてほしい。さらにに言えば、Uberがどのようにタクシーの支払い体験を転換したかも考えてみてほしい。

4. サービスが働くべき方法を再設計するためにテクノロジーを用いている

単に既存のサービスを複製するだけというよりは... UberやLyftが舞台に登場する前、インターネットに接続されたタクシーは存在していた。しかし、それらはタクシーにクレジットカードリーダーを置くために接続されていただけだった。運転手はGoogleマップを使っていたかもしれないが、誰も全体をパッケージ化しようとしなかった。

5. 業界の構造を転換する

医療に人工知能(AI)を展開するための二つのシナリオを考えてみる。一つは、非常に高価な医療装置として、AI(例えば、IBMのワトソン)を扱う。しかし、医療システムの他の部分は全て変更せずに残す。一方、革新的な企業はAI、スマートフォンベースの診断センサー、遠隔医療を組み合わせ、自宅で人々をケアするためにオンデマンドで展開できるよう、かつては低賃金の働き手をスキルアップするだろう。

テクノロジーの現在進行中の革命は、インターネット革命で最初にメディアに起こったことが全ての業界に起こる可能性を持っている。産業時代の企業はアジャイルネットワーク、アルゴリズムによる管理によって置き換わるだろう。働き手は新しい力を得て、驚くほどの新しいサービスを生み出すことができる。

ネクストエコノミーに先んじるWTFエコノミーを見ていると、ネットワークが成長をドライブするために消費者へのコストを削減するため、働き手は一筋の光を見出すことができる。ネクストエコノミーが真に成功するのに忘れてはならないのは、それらがユーザだけでなく、ユーザへのサービスを生み出す人々にとっても驚くほどの体験を作る必要がある。そして、ヘンリー・フォードが100年以上前に考え出したように、我々は製品やサービスを顧客に提供するために、働き手に十分な賃金を支払わない限り、それらのサービスが主流になることはない。

これが私の最終結論である、おまけはネクストエコノミー企業についての考えだ...

6. それらはエコシステムを作る

エコシステムは開発者やサードパーティアプリのエコシステムを意味するだけではない(Slackはどのようにそれを実行しているかを示しているが)。それは生産者と消費者、働き手と顧客のエコシステムを意味する。全ては我々がエコノミーと呼ぶ素晴らしい無限のゲームの中でお互いを利用している。ネクストエコノミーでは、ロボットやAIがエコシステムの一部でなければならない。もし、企業が単に自身の価値を引き出すためにそれらを展開するなら、そして人間のためのチャンスを低下(悪化)させるなら、我々はWTFエコノミーの中で足止めを食ってしまうだろう。

ネクストエコノミーへの進展の新しい年に乾杯。

参考

7/11/2016

TIOBEの人気プログラミング言語ランキング(2016年7月)

SlashdotがTIOBE Softwareのプログラミング言語の人気ランキングを取り上げている。

TIOBEの「プログラミング・コミュニティ・インデックス」はスキルを持ったエンジニア、講座、サードパーティベンダーの数によってプログラミング言語の人気度を評価している。7月の報告はアセンブリ言語が人気のある10のプログラミング言語の一つになっていることを示している。
低レベルのプログラミング言語がTIOBEインデックスのトップ10に再度入ってきたことに驚くべきこととして現れている。なぜ、他のプログラミング言語を使うことと比較し、様々なプログラミングの誤りに脆弱であるなら、誰が極めて生産性が低いそのような低レベルのコードを書くのだろうか? これに対する合理的な説明はアセンブリを実行できるとても小さなデバイスの数が増えているためだということだ。実に最近では歯ブラシあるいはコーヒーマシンがアセンブリを実行している。選択の他の理由はパフォーマンスである。パフォーマンスが鍵であるなら、誰もアセンブリを打ち負かすことができない。
レポートは CFML(ColdFusion)が102位から66位に、Mapleが94位から74位に、TCLが65位から48位に大幅に順位を上下させていることも示している。しかし、Javaは未だ最も人気のあるプログラミング言語にとどまっているし、CやC#もまだ2位、3位の位置を維持している。5年以上にわたり、C#やPythonは4位、5位と上昇しており(PHPは6位の位置に下落によって可能になった)、さらにJavaScriptは7位の位置を保持している(2011年には9位から上昇)。Visual Basic .NETは8位に入リ、Perlは9位である。

7/09/2016

2017年正月にうるう秒の挿入

2016年12月31日23:59:60(UTC)が挿入されるとのことだ(space.comNICT)。日本時間では2017年1月1日8:59:60となる。正月に迷惑な話ではある。

VIRL 1.2.64がリリース

VIRL 1.2.64 (July 2016版)がリリースされた。v1.0.26とv1.1.1は8月6日でサポートが切れる。OS XユーザはVM Maestro 1.2.7 dev-423をインストールしてはいけないと警告がある。修正されるまでVM Maestro 1.2.6 dev-393を使い続けて欲しいとのこと。現在、インストールはアップデートのみで、ISOやOVAイメージはまだダウンロードできない。

更新(2016.7.9)

VM Maestro 1.2.7 dev-434がリリースされた。

更新(2016.7.12)

リリース番号が1.2.50から1.2.64に変わっていたので変更。ISO/OVAイメージもここからダウンロードできるようになっている。

7/08/2016

GCEとAWS: なぜAmazonを使うべきではないのか!

AWSを使った際の苦労話

前書き

このストーリは標準的なウェブスタートアップでの私の経験を説明する。私はAWS上で数百のインスタンスを動かし、しばらくそれで動かし、持続的なペースで成長していった。

Webサーバ、データベース、マイクロサービス、git、wiki、BIツール、モニタリングと我々のすべてのオペレーションはクラウドである。それは標準的なテック企業が運用で必要となるあらゆることを含んでいる。

インターネットアクセスを提供するためにオフィスにはいくつかのスイッチとルータを残し、サイトにはサーバがなくなった。

以下のAWS上で日々出くわした多くの問題に注目し、あなたがAWSを選択したという同じ過ちを繰り返さないことを願う。

クラウドは何を提供するのか?

GCE、AWS、Azure、Digital Ocean、RackSpace、SoftLayer、OVH、GoDaddyと、多くのクラウドがある。我々の記事「クラウドプロバイダの選択: AWS vs GCE vs SoftLayer vs DigitalOcean vs ...」を調べて欲しい。

この記事ではGCEとAWSにのみ焦点を当てる。両者は大手で、十分な機能を有し、共有型のインフラで、IaaSを提供する。

双方とも典型的なデータセンターに必要な全てを提供している。

インフラとハードウェア

  • 様々なハードウェア仕様を持つサーバ
  • 地球を横断する複数のデータセンター
  • リモートとローカルなストレージ
  • ネットワーキング(VPC、サブネット、ファイアウォール)
  • 数クリックで起動、停止、削除
  • 使った分だけを支払う

追加の管理サービス(オプション)

  • SQLデータベース(RDS、Cloud SQL)
  • NoSQLデータベース(DynamoDB、Big Table)
  • CDN(CloudFront、Google CDN)
  • ロードバランサ(ELB、Google Load Balancer)
  • 長期ストレージ(S3、Google Storage)
  • ...

Amazonについて知らなければいけないこと

GCEとAWSの価格: 良い点と悪い点

AWS側の真のコスト:

  • 基本のインスタンスにストレージコストを追加
  • データベースのプロビジョンドIOPSを追加(通常のEBS IOは信頼性が十分ではない)
  • ローカルSSDを追加(800GB毎に675ドル+4CPU+30GB、常に全て一緒に)
  • プレミアムサポートにはさらに10パーセント追加(必須)
  • 専用のインスタンスあるいは専用のホストでは10パーセント追加 (規制の対象なら)

GCE側の真のコスト:

  • 基本のインスタンスにストレージコストを追加
  • GoogleリモートSSDボリュームと信頼できるすぐに使えるIOを享受
  • いずれは追加ローカルSSD(375GBごとに82ドル、既存インスタンスに付けられる)
  • 継続利用には自動的な割引(24/7稼働するインスタンスに最大30パーセント)

AWS IOは高価で一貫性がない

EBS SSDボリューム: IOPS、そしてP-IOPS

我々は信頼に足るIOを必要とするたびにプロビジョンドIOPSに支払いを余儀なくされる。

P-IOPSは実際には高速ではない。わずかに速いが最も重要なことはそれらは低下変動を持つことだ(例えば、レイテンシは90〜99.9パーセント)。通常のIOPSはとても一貫性がないため、これはいくつかの作業負荷(例えばデータベース)にとって致命的である。

全体として、P-IOPSはとても高価となり、今日あるドライブと比較してひどい(10k P-IOPSで月額720ドル、GB毎に14セント追加)。

ローカルSSDストレージ

ローカルSSDストレージはAWS上での最も高価なインスタンスであるi2インスタンスファミリー系でのみ利用可能である(そしてクラウド全体にわたり)。

粒度はない。CPU、メモリ、SSDストレージ量はいくつかのi2.xxxインスタンスタイプの間で2倍にできる。それらは4CPU+30GBメモリ+800GB SSDに、月765ドルが台数分だけ増えていく。

これらの制限はローカルSSDストレージの利用を高価にし、管理を特別にしている。

AWSプレミアムサポートは必須である

プレミアムサポートはAWSの請求書(例えば、EC2インスタンス+EBSボリューム+S3ストレージ+トラフィック利用料+すべて)に合計の10パーセントがさらに加わる。

トラフィックのスパイクに対応

ELBとS3はトラフィックの急なスパイクに対応できない。それらはあらかじめサポートによって手作業で見積もる必要がある。

計画外のイベントは503エラーで到達不能サイトになるまで5分保障されている。

制限に対応

全てのリソースはデフォルトとても低いハードコードされた割り当てによって人為的に制限されている。制限はサポートへチケットを送ることで一つずつ手動で増やすことができるのみである。

私は2つのc4.largeインスタンス(すでに15ある)を生成しようとした際のフラストレーションを十分に伝えられない。結局、”枯渇制限: 中央ヨーロッパリージョンに15 c4.large"で失敗する。メッセージがサポートされ、1日待って以後はメールとなった。そして、再度試み、"枯渇制限: 中央ヨーロッパリージョンにEBS GP2の5TB"と表示され再度失敗した。

この馬鹿騒ぎは数週間ごとに起こり、時々続けて3回制限に当たる。リージョンごと、利用可能なゾーンごと、リソースタイプごと、リソース特有の基準ごとに全てのリソースに制限がある。

制限チケットに返事をもらうため保証付き24時間SLAを支払うことになる。無料利用枠は1週間かそれ以上待たされ、その間は動かすことができない。それがプレミアムサポートを押すばかばかしいが実際の理由である。

AWS側での障害の対応

インフラで何が起きたかのログなし、兆候なし。サポートは何か問題が起きたら要求される。

例えば。ELBが不規則にリクエスト落とし始めたとする。サポートに連絡した後、彼らは何が起きているかの見解を持っていないと応答し、そして対応策を取る。「リクエストに感謝にします。ELBの一つが変な動きをし、我々はそれを停止し、新しいものに取り替えました」。

問題は修復された。悲しいことに、彼らは見解あるいは有意義な情報を提供してくれない。これはデバッグや障害の予兆を探る上で非常に痛い点である。

注意: 我々はスタックに導入されることからさらに管理サービスに集中砲火をしている。最初はセットアップが簡単なので、それらが試された(制限された人的時間とちょっとした好奇心)。それらはすぐに周期的に問題を起こすことがわかった。その上、デバッグやトラブルシュートが不可能である。

ELBは多くの作業負荷には不向きである

[HNのコメント後に更新]

ELBはホスト名でのみアクセス可能である。基本的なIPは60秒のTTLを持ち、すぐに変更ができる。

これは固定IPが必要で、また起動時に一度だけIPを解決するすべてのサービスにはELBが不適当であることを示している。

ELBは障害時にデバッグが不可能である。それらは急なスパイクに対応できないし、CloudWatchグラフはひどい。(素直に言って、我々はCloudWatchを全体で置き換えるためにノードごとに月18ドルをDatalogに支払っている。)

ロードバランシングは高い可用性とスケーラブルなデザインのコアな特徴である。冗長性のあるロードバランシングは次に重要な特徴である。ELBはタスク次第である。

ELBの代替はVRRP/keepalivedを持つHAProxyのペアを我々自身でデプロイすることである。適切にセットアップし、稼働中にデプロイするのに数週間要した。

比較によって、我々はGoogleのロードバランサでは数時間で達成できる。Googleのロードバランサは一つの固定IPを持つことができる。そのIPは1k/sから10k/sまでリクエストをトラフィック落ちなく直ぐに受けることができる。ちゃんと動く。

注意: 本日、我々は稼働中の1台のサーバが500/sから15000/sの要求を3秒未満で返すことを確認した。我々はその半分となるELBを信頼していない。

専用インスタンス

"専用インスタンスは一つの顧客向けの専用ハードウェア上の仮想プライベートクラウド(VPC)の中で動いているAmazon EC2インスタンスである。あなたの専用インスタンスは専用インスタンスではないインスタンスや他のAWSアカウントに属するインスタンスからホストハードウェアレベルで物理的に分離されている。"

専用インスタンス/ホストは法令遵守、法的要求事項、not-having-neighboursのためにいくつかのサービスにとっては必須かも知れない。

我々は規制に従う必要があり、あちこちで専用オプションを持っている。それはインスタンス価格に10パーセント上乗せする(リージョン毎に毎月の料金が固定で1500ドル加わる)。

注意: Amazonは必然的な重要な詳細を説明しないし、明確な約束もしてくれない。不思議なことに規制者(regulators)も今までそれを指摘しなかった。

HNコメントへの回答: Googleは「GCE専用インスタンス」を提供しない。その必要は全くない。コツは規制者やエンジニアが存在しない何かを持っていないことについて不満を言わないことである。

インスタンスの予約はデタラメである

予約は特定のリージョン、利用可能なゾーン、インスタンスタイプ、テナントなどに付けられている。理論的には、予約は修正できるが、実際のところは何を変更するかに依存する。いくつかのパラメータの組み合わせは修正できるが、他はできない。計画は慎重に、そしてまず試して正しく理解する方が良い。

予約中はインスタンスが動いているか動いていないかは関係なく、毎時で支払いが発生する。

割引は小さい。たくさんの予約の中の見当はずれの予約は今までのところ全ての割引を簡単にキャンセルできる。そして、誤りを訂正するためにサービスをあちこち移すのに多くの日を割くより、あらかじめインフラ全てをレビューするのに長い日にちが掛かることを覚悟しておくこと。

予約インスタンスは6-12か月ごとに起こるいつもの価格下落から恩恵は受けないということを覚えておくこと。

GCEと比較すると、毎月の自動割引は本当に素晴らしい。インスタンス時間は毎月終わりに集計され、割引が自動的に適用される(例えば、インスタンスが24/7動いていれば30%割引される)。アルゴリズムも簡単な方法でインスタンスの起動/停止/更新を組み合わせられ、非常に手助けとなる。

AWSネットワーキングは平均以下

ネットワーク帯域の割当量はインスタンスのサイズと関係する。

1-2コアのインスタンスはピクで100-200Mbps、これはこの世界ではとても小さい。ネットワークに依存する多くのことがあるので、もっともっと接続されるべきである。

帯域制限があるため、遅くなる典型的な作業:

  • インスタンスプロビジョニング、OSのインストールと更新
  • Docker/Vagrantイメージデプロイメント
  • sync/sftp/ftpによるファイルコピー
  • バックアップとスナップショット
  • ロードバランサとゲートウェイ
  • 一般的なディスクの読み書き(EBSはネットワークストレージ)

我々の最も重要なバックアップは稼働ホストから別サイトロケーションへのコピーに97秒掛かっている。半分はネットワークの帯域幅が飽和し(130Mbpsの帯域幅制限)、半分は受信ホスト上のEBSボリュームが飽和している(最初の転送の間、ファイルはメモリにバッファされており、100%のiowait、EBS帯域制限がある)。

同じバックアップ操作を同じハードウェアを持つGCEだと10-20秒で終わる。

コスト比較

この投稿はインスタンス価格比較なしに完全ではない: GCEとAWS間の典型的なコスト比較

あちこちに隠れた手数料 + 信頼できない性能 = 次善策で人的時間の無駄

キャパシティ計画と日々の運用

キャパシティ計画はスケーラブルではないリソース、信頼できないパフォーマンス能力、不十分な粒度、あちこちにある隠れた制限では余計に辛い。計画費は悪夢だ。

常にインスタンスを追加する必要がある。その度にインスタンスページ、料金ページ、EBSページを何度も読む必要がある。とても多くの選択肢があり、後で変更するのが難しい。それは紙に印刷すると、A4x7フィートのテーブルを覆ってしまう。比較すると、Googleから適切なインスタンスを選ぶのにはたった両面1ページで済む。

最適化使用法は失敗する運命にある

最適な予約インスタンスを取る時間は値引きと同じコストである。

CPU数、メモリサイズ、EBSボリュームサイズ、IOPS、PIOPSの間で、全てがAWS上でオーバープロビジョニングである。一つには、人が行うためのフォローや最適化にはとても多くの事があるためで、一つには一貫しない能力に対する次善策として、一つには稼働中のインスタンスを後で修正するのが難しいためである。

これら全ての問題は直接的にAWSプラットフォーム自身に関連しており、整理されておらず、簡単には水平方向への拡張もできないし、ハードウェアオプションでもなく、ハードウェア能力でもなう、金銭的なものでもない。

常にコストをオアせるために何かを変更することについて考えていて、いつも何もしないことよりも費用が掛かっていた(エンジニアリング時間の会計処理の時)。

むすび

AWSはたくさんの隠れたコストや制限がある。システム能力は満足感が得られないし、一貫した拡張ができない。AWSを選択したことは間違いだった。GCEは常に良い選択である。

GCEは体系的に同等のインフラで最適化を考慮せずに20%から50%安価である。大事なことを言い忘れていたが、しかも速くて、信頼性があり、毎日の運用が簡単である。

我々の会社の未来

残念ながら、AWS上で動いていた我々のインフラを移行するのは容易ではない仕事である。

私は当時、私が考えていたよりもっと我々は利益のある会社であることを学んだ。従業員あたりの収入によるトップ10企業を見て欲しい。我々はトップ10の中にいる。我々はいずれ近いうちにAWSで行き詰まり、多くのお金を投入して問題に対処していただろう。会社は費用をカバーできるし、コスト最適化は今のところは最優先ではない。

「お金で問題を解決する(throwing money at a problem)」ということわざがある。我々は現状を表すのに今後は「家で問題を解決する(throwing houses at the problem)」と言うだろう。

現在のペースで成長し続けるには、垂直に拡張する必要がある。我々は「ビルでAmazonを解決する(throwing buildings at Amazon)」という意味である。

Hacker News

7/05/2016

黒人有権者のトランプ支持は1パーセント

クイニピアック大学の世論調査によると、黒人有権者のトランプ支持は1パーセントで、誤差+/-2.4%ということは、マイナス1.4パーセントかもとのこと(Boingboing)。

Trump at 1percent

7/02/2016

Android Nの愛称は「ヌガー (Nougat)」

John Gruberはこう書いていた。

私はI/Oで発表された「名前を募集します」コンテストは全くの嘘っぱち(bullshit)だったと思う。彼らはそれでもヌテラ(Nutella)で話し合っていたと思うが、うまくいかなかった。そして、今ではつまらない名前のヌガーを決めかねている。