絶品ゆどうふのタレ

ふと気づいたことを綴るだけのメモ

AWS Summit 2015 - Day1 - Aurora Deep Dive

AWS
  • AWS 星野さん

Auroraについて

  • RDSの5番目のエンジン
  • クラウド時代に特化した新しいDBエンジン

  • エンタープライズグレードの可用性とOSSレベルのコスト

  • previewだが、5/20からproduction環境に移行

  • 料金体系

    • R3シリーズのみの提供
    • ライセンス料は不要
    • MySQLとのコンパチブルを保つ
      • ロックインはない

  • 特徴

    • MySQL 5.6との互換性
      • マイナーバージョン指定は特にしない
    • ストレージが10GB - 64Tまで自動で拡張
    • 3AZに２つずつ、６つのコピーを保存
    • VPC内に起動
    • 99.99%の可用性

なぜデータベースを再考したか

  • モノリシックなDB

    • 複数の機能レイヤーが１つのアプリケーションになっている
    • スケールアウトする場合、このセットで増やす必要がある
    • コスト・可用性・柔軟性の問題

  • 今、再実装するならどうなるか？

    • 1970年代の方法では実装しない
    • スケールアウトが簡単で、セルフヒーリングなもの
    • AWSと簡単に連携したい

  • これをフルマネージドで提供する

アーキテクチャ

  • ログレイヤ

  • ストレージレイヤ

    • バックにスケールするストレージサービスを採用
    • EC2 / Dynamo / SWF などを管理コンポーネントに採用

  • キャッシュレイヤの分離

    • キャッシュをDBプロセスの外に置いた
    • DBを再起動しても、キャッシュが残る

  • ストレージ

    • 6つのストレージにコピー
    • 一部のストレージに書き込みが多くなった場合、一部のホットスポットを取り除く
    • SSDベースで10GBずつのブロックに分散して書き込む

  • リードレプリカも同じストレージを参照

    • 壊れた場合も再ストレイピング、ミラーの修復なども自動で走る

  • Log Structured Storage

    • 追記型のストレージシステム
      • 常に末尾にデータ追加
      • GC
    • 新規データは末尾に追記
    • これが10GBのチャンクごとに書き込みが行われる

  • ディスク障害検知

    • 2つのコピーに障害があっても読み書き可能
    • 3つ障害があっても読込は可能
    • 自動検知して修復

  • レプリケーション

    • Binlogによるレプリケーションではない
      • 同一のディスクを見ている
    • マスターの負荷を最小限にしつつ、15台のリードレプリカを作成可能
    • 同じデータのディスクを参照しているので、フェイルオーバーしてもデータロスがない

  • セキュリティ

    • データの暗号化
    • SSL
    • 直接ログインは不可

  • DBクラスタ

    • DBクラスタという概念を持っている
      • マスタとリードレプリカ
    • DB Parameter Group / Cluster Parameter Group

  • 新しいメトリクス画面

    • キャッシュ・CPU使用率についてわかりやすくなる

  • フェイルオーバーとリプレース

    • リードレプリカがある場合は1分程度でフェイルオーバー可能
    • 優先的にフェイルオーバーさせるノードを指定可能
    • ノードリプレース時の起動先AZを指定可能

  • クラスタエンドポイント

    • WriterのCNAMEになっていて、壊れたら別の新しいノードに切り替わる
    • Readerはそうはなっていないので、アプリケーションで対応

  • 高速なデータ修復

    • 並列、分散、非同期で行われる

  • Streaming snapshotとPITR

    • バックアップを残す期間を指定可能
    • 任意の時間に秒単位で戻すことが可能
      • 現在では、2分前のデータから可能

  • SQLによるフェイルオーバーのテスト

    • 擬似的に障害をシミュレート

パフォーマンスを引き出すために

Auroraの使いドコロ

  • 同時実行数やテーブルサイズが大きい場合

    • そのままうつせばOK
    • 性能向上の恩恵を受けやすい

  • 複数のサーバにシャードしている場合

    • 複数のDBをひとつのノードに
    • 管理コストの低減

  • 単発のクエリとかが早くなるわけではない

    • インデックスも同様
    • そこのチューニングは今までどおり
    • Explainの結果が変わる可能性は十分ある

AWS Summit 2015 - Day1 - Amazon CloudSearch Deep Dive

AWS
  • AWS 篠原さん

SnapDish事例

  • ランチセッション

    • ランチといえば
    • お弁当どうしよう

  • CloudSearchで検索を入れてる

そもそもどういうさーびす？

  • フルマネージドな検索エンジン

    • 多言語対応 34言語
    • ハイライト、サジェスト、地理など

  • AWSの中ではマイナー

  • Amazonで買い物すると。。。検索の下でA9というのが出る

  • スタンフォードにA9.com
    • そこで作ってる

どう使う？どういうもの？

  • 南北線の検索をしたい

    • 海外で発表したら、東京都地下鉄やばいという話になった

  • 検索ドメインの作成

    • 南北
  • JSONで駅のコード、駅名などのデータファイルを作成(SDF)
  • upload
  • すると、勝手にスキーマ定義
    • フィールド指定にDynamic Fieldも使える

  • プルダウンで選ぶだけで、日本語でのトークナイズができる

  • あとはもう、検索すれば出る

    • OR検索とかも出来る

  • 形態素解析

    • 辞書のカスタマイズが可能
    • データファイルを作って、定期的に辞書に取り込んだり

  • シノニム・類義語

    • これらもWebやCLIから登録できる

  • Bi-gram Index

    • 言語をMultiple Languageにセットすれば使える
    • 2文字ずつで切るとノイズが発生
      • 東京都と京都

  • 形態素解析とBi-gramを組み合わせて使う

    • SourceField
    • 両方でor検索的にして、形態素解析側を優先する

  • ソート順はTF-IDF

    • ドキュメントにその言葉がいっぱい出てくるなら、高スコアにする

  • 様々なexpression

    • 結果の重みづけ、調整ができる

  • A/Bテスト機能

    • 重み付けを変えた場合の結果を比較する機能

  • 複数の方の組み合わせ

  • よみがなをベースとしたSuggestion

  • 可用性、IAMによる管理

    • AWS Security Blogにもいい例がある

Inside Amazon CloudSearch

  • フルマネージド

    • Auto Pertitioning
    • Auto Scaling

  • 中身がどうなっているのか？

Indexing

  • 中身はELBがいて、その裏にEC2が並んでる状態
  • データを保存する場合に、どれかのノードに送られる
  • そのノードが、ひとまずレスポンスを受け取った上で、DynamoにUpload。その後は非同期処理
  • 定期的にS3/Dynamoにポーリングして、担当の処理があれば処理・Indexを作る

Query

  • 受け付けるところまでは同じ
  • 一般的なEC2の場合と同じAutoScalingが動いている
  • クエリの量が増えると、それによって増える

AutoPertitioning

  • データ容量の増加にどうやって対応してるか

  • 最初はスケールアップ

    • なので、ダウンタイムはないが切り替わり中はIndexingが反映されないことがある

  • １ノードでまかないきれなくなったら、スケールアウト

  • パーティション分割処理はHadoop(EMR)

  • 検索ドメインの変更など

    • 同様にEMRで

初期のデータを投入する場合

  • 予め大きいインスタンスをたくさん並べると、短時間でIndexing処理できる
  • インスタンスタイプのデータ量の目安
    • データのタイプに依って圧縮率が変わるので、どうしても差が出る

大量のリクエストに備えて事前対応

導入事例

  • schoo

    • 爆速で導入
    • リリースまで1週間

  • nanapi

    • デフォルトのまま使ってる
    • それでもいい感じに検索できている

  • Chatwork

    • 日本最大級の利用例
    • 5億件以上のデータ
    • 運用はほぼメンテナンスフリー
    • CloudSearchにして速度はかなり改善した

更に知りたい方に

  • DocValues
  • CloudSearch SAのビデオ
    • たとえば、普通のqとfq(filter query)の性能差とか

AWS Summit 2015 - Day1 - keynote

AWS

Keynote のメモ

AWS Japan CEO 長崎さん

  • 昔Jeffが書いたメモ

    • 低コスト構造を作り、それをローコスト化につなげることで、顧客満足度が高まる
    • この構造がアマゾンのモデル

  • スケール、スピード、イノベーション

  • AWSはクラウドを作ろうとして作ったものではない

    • 店舗がないので、テクノロジーが命
    • サーバが間に合わない、などは命取り
    • 顧客の価値にフォーカスしろ！
      • 社内調査した所、開発者の時間のほとんどが、サーバのおもりに費やされていた
    • ビジネスをより早く
    • ワンクリックでサーバの準備が出来るようにし、インフラをプログラマブルにすることで価値にフォーカスできる

  • S3は年間102%の成長率

  • EC2も93%の成長率
  • 100万のアクティブユーザー
  • 多くのパートナー企業
  • 増え続けるAWSソフトウェアとSaaS
    • ESP
    • 冊子にしました

  • ユーザーコミュニティ

  • クラウドは今やニューノーマルに

    • 特定の先進的な企業が使うものから、普通の企業が使う当たり前のソリューションに

  • スタートアップによるビジネスの開始

    • やりたいことが即座に低コストに、初期投資を抑えて変動費に
    • スピードを重視

  • aribnb

    • ５人のエンジニアがAWSを使って運用している
  • Dropbox

クラウドワークス 吉田さん

  • 昨年上場

    • 36で一度ビジネス失敗
    • そこから再スタート
    • AWSで始めて、3年でここまできた

  • クラウドソーシングとは

    • 新しい外注方法
    • 個人に対する発注
    • 個人の労働力を企業が活用できる

  • 歴史的に、経営は持たざる経営が進む

  • 利用は9万社を突破
    • 時価総額ランキングトップ10中8社が利用している

  • 東証の鐘はユーザーに叩いてもらった

  • 年収1000万でクラウドワークスで稼いでいる人もいる

  • 新しい形の地方創世

  • ガイアの夜明けで次回取り上げてもらえる予定

    • 錦織の試合が無ければ、今夜ｗ

  • 100% AWS上で完結している

リクルートテクノロジーズ 中尾さん

  • 海外に1000拠点

  • ビジネスは「リボンモデル」

  • 2年半前に分社

  • リクルートは400以上のサービスを展開

    • テクノロジーズは、そのITを支える
    • 現在400名の会社

  • どうつかっているか？

    • トラフィックが予想できるものは、オンプレ
    • できないものは、AWSを利用している

  • Speed

  • Flexbility

  • Fanctionality

  • キャンペーン等のトラフィックが予想できない場合に有効

  • 同時にpush通知を送る場合
    • 秒間に14000に送れる

長崎さん

  • 素早いプロビジョン

  • それをすぐに縮退できるか

  • コアなサービス部分

  • 既存の資産を容易にするサービス群

  • Gartner

  • 実際の業務のサイズ・形は千差万別

  • ニーズに合ったプラットフォームを用意することで、これを解決してきた

  • 共有ファイルシステムの課題

  • ９年の運用実績

    • 既存の資産を運用するのとは、全く違う規模感

  • データの収集・保管・分析・共有はとても困難だった

  • 多くの企業が、ビッグデータ分析をAWSで実施

  • 機械学習を利用する顧客が急増中

  • Amazonは元々レコメンデーションで機械学習を利用

  • これをもっと社内で活用できないか？

  • Amazon Machine Learning

    • フルマネージド型機械学習サービス
    • ハードウェアも気にしなくて良い

  • Aurora

    • MySQLと互換のストレージエンジン
    • ハイエンドMySQLの5倍以上の性能

  • Amazon WorkSpaces

    • ソフト・ハードの管理不要
    • 様々なデバイスからアクセス可能
    • 月額利用オンプレより半分の価格

  • Amazon ECS

  • Amazon Lambda

    • コンピューティングリソースを極小化
    • イベントをトリガーにコンピュータを起動
    • そのイベントの時間しか課金されない
    • 100msならその分だけ

  • 第三者認証と監査により証明された、高いセキュリティ基準と運用基準

ファーストリテイリング CIO 玉置さん

  • 売上高1兆3800億円！

  • 作るシステムは最初からグローバル

  • 直感的に、マニュアルいらずでどのデバイスでも動く

  • スピードに応えるクラウド

  • なぜAWS?

    • 重視しているのは、Large Community
    • エンジニア・デベロッパーを惹きつけて、自発的なエコシステムを作る魅力がある
    • ここに非常に魅力を感じている

  • 瞬間で、11万リクエスト/sec

  • 正直、サイジングがきちんとあたった覚えが殆ど無い

  • そんなものよりAWSのスケーリングにかけている

  • マルチリージョン

  • Now Hiring!

長崎さん

  • 「重力」には逆らえない
    • 変化や未知のものはだれでも怖い

画像変換Nightに行ってきた

image
  • http://connpass.com/event/11516/
  • とりあえず、見つかった限りのスライドは載せました。
  • 発表者のみなさま、会場のGREEさん、ありがとうございましたm( )m

感想・まとめ

  • 全体的に濃い話だった
  • go-thumber使ってみたい
  • 基本的にみんなImageMagick大好き
    • というか、あまり他に優秀なインターフェースがないんだな、の印象
  • yoyaさんは神
  • 自力でやりました、という話が中心で、こうやって楽にやってますという話はなかった
    • 切り出しとか考えると、ASPつらいのかもね
    • でもCloudinaryすごいよ？
  • ImageHayabusaへの期待感すごい

サムネイルマスタとgo-thumber

  • はるかさんさん

  • pixivのひと

  • オリジナル画像をそのまま配信

    • 転送量がめちゃ多い
    • デザイン大変
    • 後からサムネイル作るの大変
    • サービスが大きくなるにつれ、つらくなる

  • アップロード時にサムネイル生成

    • アップロード処理が大変
      • 非同期処理必要になる
      • そうしないと待たせちゃう
    • サイズ変更が大変

  • リクエスト時にサムネイル生成

    • 動的変換
    • デザイン変更が簡単
    • キャッシュしてくれればリクエストも少ない

  • 動的生成で困ること

    • 生成元画像に依存
      • サイズもバラバラでメモリ量もバラバラ
    • 処理が面倒
      • フォーマットの問題
      • 加工とかとか。。。

  • サムネイルマスタ

    • サムネイル生成元となる画像マスタ
    • リクエスト時の生成の負荷を軽減
    • 他のサムネイルよりでかい
      • 長年培われたcrop技術により。。。縦長は下が切られる

  • 画像はJPEG保存

  • JPEG/EXIFの問題

    • ブラウザによってICCプロファイルを解釈したりしなかったり

  • CMYK JPEG表示できない問題

    • 一度pngにしてJPEGに戻してる。。。

  • どうすればよいのか

    • カラーマネジメントできるエンジニアが不在
    • ユーザー環境がただしいプロファイルを扱っているかわからない

  • これらの問題をサムネイルマスタで解決

    • JPEGN/JFIF互換のJPEGを作る
    • etc...

  • go-thumber

    • サムネイルマスタをいい感じに作ってくれるプロキシ
    • はやい
    • LibJPEGv6 APIを生で叩いて書き込み
    • LibswscaleでImageMagickと同等の精度

  • ベンチマーク

    • mod_smalllight(imlib2 / imagick)と比較
    • Apacheはあんまり頑張ってない
    • だいたいimlib2と同じくらいの速度になった

  • ブラインドテストをやった

    • 50%ぐらいの人が、go-thumberのサムネイルを一番きれいだと選択した

  • 何故綺麗に出たか？

  • スケーリングデコードのサイズ最適化

    • libJPEGは1/1 - 1/8の好きなスケールでデコードできる
    • go-thmberでは必ずサイズの2倍に設定してる

  • 次はwebp-thumbersを目指してる

  • Q: URLにパラメータが直接見えると、だれでも変換できるが？

    • A: nginxのrewriteで特定のものだけ通してる
      • 開発環境ではフリーに通してる

実践ngx_small_light入門

  • bokkoさん

  • Mercari, Inc.

  • ngx_small_light

  • setup / install / 設定

  • small_light on;

  • small_light_pattern_defineで名前を付けられる

  • 基本的なパラメータ

  • small_light_getparam_mode on;

    • query stringから指定できる
    • デフォルト off
    • 設定するとsmall_light関数は使えなくなる

  • S3にある画像をngx_small_lightでリサイズ

    • リゾルバの設定が抜けてた

  • 画像ライブラリの比較

    • それぞれ特色ある

  • その他のモジュールについて

    • mod_small_light
      • ngx_small_light のポーティング元
    • ngx_image_filter
      • 標準で付いているimage filter
    • go-tumber
      • pixiv制

  • Image最適化について

    • worker_(processes|connections)
      • worper_processesは多めに
      • worker_connectionsは少なめに
        • nginxとは逆ｗ
      • nginxがイベント駆動であることは忘れるｗ
    • JPEG Hinting
      • 本当は早いImageMagickでググれ！
      • jpeghint=y
        • JPEG以外では無視される
    • libjpeg-turbo
      • x86 /x86_64に最適化されたlib
    • OpenMP
      • マルチプロセスだと劇的にスローダウンする
      • 無効にするには、-disable-opempで再コンパイル
      • OMP_NUM_THREADS=1の環境変数
      • nginxは起動時にTZ以外の変数を削除するので、envディレクティブでちゃんと入れよう
    • WebP
    • Cache

ImageMagick + WebP

  • mirakuiさん

  • WebP

    • ウェッピーです！！！！！！

  • なぜWebP?

    • 小さい
    • JPEGに比べて画質が劣化しにくい
      • 半分以下ぐらい

  • WebPの欠点

    • 対応環境が少ない
    • 右クリックで画像を保存、でJPEGが欲しい人達がいる
      • Webだと変な不評がでる

  • ネイティブアプリなら。。。

    • Android 4.0以降なら大丈夫という噂もあるが。。。真に受けない方がいい
    • 4.4以上で有効にしてる

  • Tofu

    • ImageMagickが対応してる
    • 調査すればノーコーディングでいけるのでは

  • yoyaさんのブログを見る

    • 6.6.8から対応してた！

  • ただ6.6.8でのWebPはぶっ壊れてる

    • 画質の指定ができない
      • Quolity=0とは。。。
    • リサイズ、クロップ周りがバグってる
    • CMYKが狂う
    • メモリリーク

  • ChangeLogを追う

    • 6.8.6-8まで。。。

  • ImageMagickのバージョンアップ怖すぎ問題

    • 絶対避けたいこと
    • ImageMagickのバージョンアップで画像の色味が変わってしまうこと
    • 全てをチェックするのは無理

  • yoyaさんに相談

    • 6.8.7からは色空間の扱いが変わった
      • ここで色味が変わる可能性がある

  • WebPにはどのバージョンを使えばいいか

    • 6.8.6-8まで上げれば、必要十分
      • 6.8.7からは色味が変わる可能性がある
    • これから使う人は、最新を。

ImageMagickアレコレ

  • http://diary.awm.jp/~yoya/data/2015/02/18/ImageMagick-something.pdf
  • yoya

  • 今回はImageMagick 6だが、本家は既に7前提

  • 6と7の違い

    • ディレクトリ名が違うだけ。。。

  • ImageMagickってなんだっけ

    • 画像を処理できる何か
    • コマンドがある
    • いろんな言語から使える
    • フォーマットがたくさん
      • 100種類以上のマイナーなものまで
      • cssのinlineフォーマットまで対応してる

  • MagickCoreというエンジンと、プラグインcoder集合体と、ユーティリティ的なMagickWand API

  • ImageMagickの開発傾向

    • 活発すぎる
    • APIのバイナリ互換とか気にしない
      • コレに切れてforkしたのがGraphicsMagick

  • バージョン毎に声質が違う

    • 全バージョンをそろえるｗｗｗ
    • 600ぐらいビルドｗ

  • 全バージョンで実行

  • QuantumDepth

    • Q8/Q16
    • RGBの各値を8bit/16bitのどっちで持つか
    • 普通の人間の目なら8bitで十分
    • ImageMagickはデフォルトQ16

  • Q8の問題点

    • 医療用画像などではQ16なので使えない
    • HDR等のフィルタでちょっと荒くなる

  • OpenMPが重い

  • JPEG画像変換

    • 何故JPEGHintが早いのか

  • 最近のトピック

  • 6.8.7-4がエポックメイキング
    • OpenCLガチ対応
      • Cのコードとは別に実装してるので、フィルタが全く同じになる保証がない
      • 確認して使った方がいい
    • 減色処理高速化
      • GIFアニメ生成が早くなった
  • 6.8.8-2
    • icoファイルをauto-resizeできるように

  • 6.9.0-4

  • GIFアニメ最適化

    • 変化のある部分を切り出して、透明にして軽量化

  • GraphicsMagickは？

    • GIFアニメ生成が早いのは、実は単にエンジンが古いだけ
    • GraphicsMagicはQ8デフォルトなので、比較するなら同一にしないとアンフェア

  • ImageMagickを弄りたくなった人へ

    • Cristyさんはコミットコメントを書かないｗ
    • コードはきれいなので、意図は伝わる。。。

RICOH THETAの全天球画像でペーパークラフト

1px interpolation

とあるECサイトに動的画像変換を導入した話

  • GMOペパボ yano3

  • カラメル

    • ショッピングモールサイト

  • 動的画像変換はしてなかった

    • 提供元によって画像の仕様はさまざま

  • おから(仮)

    • 動的画像変換サーバ
    • ngx_small_light

  • ハッシュ値があってたら、動的生成に投げる

  • 今後

    • WebP

ngx_small_lightの利用事例

  • 導入の経緯
    • バックグラウンドジョブで変換してたが、時間かかる

  • WebPの経緯

    • 通信の改善

  • VagrantでCore OS VMからPushして、infratasterでCI、Merge押すとQuary.ioでビルド

  • CoreOSインスタンスを立てて切り替えて古いものを消す

    • どのサーバでも同じフローで

  • 遭遇した問題

    • WebPの変換がおかしい
      • mirakuiさんにきいたｗ
    • nginxがcoredump吐く
      • ImageMagickの初期化タイミングの問題だった
    • nginx異常に高負荷になる

JPEGのDCTブロックでコンテンツ指向のトリミング

  • 4_sukeさん

  • コンテンツの場所を考慮して切り取ってくれたらいいのに！

  • Facebook

    • 顔認識の結果をベースとしているらしい
    • 顔認識は計算リソース必要
      • 保存するとしても、ストレージ必要
    • 顔以外は認識してくれない

  • JPEGエンコーダに手を加えればいいんじゃね？

    • DCTブロックを直接参照すれば！

  • JPEGデコーダの処理で高周波成分の部分を中心に切り取る

  • JPEGデコードの過程でDCT変換したデータが得られる

    • 高周波成分が集まってるところが、経験則的には中心ぽくなる

  • ハフマン展開 + 逆コサイン変換を DCT変換の後に追加

    • 人がたくさん入ってくると、平均化されて真ん中が切り抜かれがち

  • まとめ

    • ナマの画像にそのまま使うので、計算量が少ない
    • 追加実装も少ない
    • 顔認証と違い、なんでも大丈夫
    • JPEGにしか適用できない
    • 文字が入ってると弱い

  • jpgjsに手を入れた

  • pixiv方式とどちらがいいか？

    • どれだけコンテンツに対する仮定を置くか
    • 何がメインか、によって違う
    • 仮定を踏まえて定量評価するしかない

ImageHayabusa

  • Guntherさん

  • http://hayabusa.io

  • デザイン作業効率化

    • 素材の切り出しや必要な素材サイズを毎回デザイナーにお願いしないといけない
    • これを一発で

  • メリット

    • 作業が楽になる

  • パラメータで様々な変換ができる

    • PSDの特定のレイヤーを指定して書き出しもできる

  • 初回は生成、２回目以降はキャッシュ

  • CSSも出力し、中で使っているフォントもわかる

8086命令セットの細かいメモ(2)

8086 assembler binary cpu

今日もまた、細かいけどためになる話を教えてもらったのでメモ。 自分で事後補足として調べたものも含むので、用語が正確じゃないかも。ツッコミ希望。

NASMがpushf(9C)/popf(9D)の機械語をpushfw/popfwとディスアセンブルするのはなぜか？

これはすごく歴史的経緯が深いやつで、16/32/64bitのCPU命令の拡張に伴う変更に起因するもの。 inc/dec命令その他複数の命令も同様の事情を持っている。

instruction prefix

この話に関係するのは、instruction prefix(命令プレフィックス)と呼ばれる、16/32/64bitの切り替えと互換保持などのために用いられる機能。

特に16/32bitの命令切り替えに関連してくるのは、

  • The operand-size prefix (66H)
  • The address-size prefix (67H)

といった、オペコードの前に置かれるprefix。これが配置されることで、その後ろの命令のオペランドサイズを切り替える。

pushf/popfにおける具体例

表題の疑問の回答。例えば、

bits 16
pushf
pushfw
pushfd

は、アセンブルすると

9C
9C
669C

となるが、

bits 32
pushf
pushfw
pushfd

は、

9C
669C
9C

となる。 逆アセンブルの場合も同様で、-b 16では

9C   pushfw
669C pushfd

だが、-b 32では

9C   pushfd
669C pushfw

という解釈になる。 ちなみに、16bit命令のpushf/popfと等価なものはpushfw/popfwであり、pushfd/popfdは32bit用命令セット。

64bitになると、32bit時代の命令であるpushfd/popfdは廃止され、64bit用にpushfq/popfqが加わる。

予想だが、16bitのものが残って32bitのものが消えたのは、　16bit機能がリアルモード/プロテクトモードの切り替えで意識する必要があるからではないか、と思っている(正解はまだ知らない)。

REXプレフィックス

64bit化の際には、このprefix以外に、さらにREX prefixが導入された。 その導入のために、inc/dec命令の領域を再配置し、その一部がprefix用に再利用されている。

同じ命令が複数の方法で表現可能な理由

例えば、

mov ax,0x12

は、以下の２通りで表現可能。

B012
C6C012

このように、なくなってもいい or 他の方法で表現できる命令が時々存在する。

何故こんなのがあるかというと、よく使われる命令セットを1つのショートカット機能で実現することでbyte数の節約に役立てる、というのが存在理由らしい。

ここは自分の推測だが、CISCの思想というのはつまり、こういうことなのかもしれない。メモリ大事。

addのImmediate to Register/Memory命令でs:w = 10が無い & s:w = 11でdataが1byteなのはなぜか

フラグの意味は以下のとおり。

  • s: signedの意。数値に+/-がつくアレ。
  • w: addの演算がbyteの演算かwordの演算か。

加算命令ではあるが、コンピューターの世界では桁あふれと補数の存在によって減算も行われる、というところまでが前提。

sフラグは、wordの世界での下桁1byte分の減算を実現している。 計算としてはsのフラグなしでも全て成り立つのだが、sを導入することで0XFFxxと加算する場合と比べて1byteが節約できる、というのが(おそらく)このフラグの目的で、同時にs:w = 11でdataが1byteだった理由。

そして、byteの演算にはsignedを持ち込む必要性がなかったために、s:w = 10の演算は定義されなかった、ということのようだ。

ざっくりまとめると

  • 1byte + 1byte なら引き算考えるときsignとか不要
  • 2byte + 2byte も同じくsign不要
  • 2byte + 1byte分の引き算をする時、signedで考えると1byteケチれる

という話。

ちょっとした感想

こうしてアセンブラと機械語の対比を見つつ歴史的経緯を知っていくと、一見なんだか意図の読めない命令セットの中の、CPUの進化・効率化と互換性確保のバランスを綱渡りしてる感じが垣間見えて、非常に面白い。

全命令セットを実装していくのは冗長な作業では、と最初は思ったけど、このへんを知るにつけ意味のある作業だと実感が強まってて良い。

8086命令セットの細かいメモ

8086 assembler binary

勉強会で教えてもらったので、忘れないようにメモ

pop csが無い理由

xchg ax,ax -> nop の理由

lea ax,axなどの命令が割り当てられていないのはなぜか

  • lea ax,[bx]
    • ax = bxの代入
    • カッコを外して代入をする命令
  • lea ax,[bx+5] と、ディスプレースメントつきの場合
    • ax = bx +5 の計算が1命令で出来て便利、という使い方
  • そのため、lea ax,axの命令だと、そもそもカッコがないので、この命令はありえない。
    • なので、この命令はない

in, out命令のword/byte切り替えについて

  • portの指定が1byteのままなのは何故か？

  • I/O空間自体は、0000 - FFFFまである

  • しかし、この中で即値で指定できるのは00FFまで。
  • それより上については、dxに入れて(Variable Portで)使う。
    • おそらく、8080とか8bit時代の仕様を引ずっているのでは。

Go Conference 2014 autumn に参加してきた

Go event

GoCon2014秋にいってきたよ！ とりあえず、まとめと見つけられた分のスライド載せました。

先にまとめ

  • 朝から全開で実用的な話が多く、ためになる話多かった。
  • Goの哲学をRob Pike先生本人から聞けるなんてなかなか無いですよね。
  • 8時間ハードだった
  • ケツ痛い
  • 英語力磨かねば。。。
  • スタッフの皆さん、発表者のみなさま、会場＋協賛をしてくださった楽天さん、Klabさん。素晴らしいイベントを有難うございました！

Keynote

  • Rob Pike

Goはなぜ成功したか

  • シンプルさ、こそが本質
    • 他の様々な言語は、複雑すぎる

  • 各言語は、他の言語のいいところを吸収しあうことで大きくなり、複雑化して発展してきた

  • Goはそれをしない

  • Go1の時点で言語機能は固定化された。

    • 色々な機能を追加してほしい、という声がある、が、それは追加しない。

  • もちろん、いくつかの機能は必要

    • 正しい機能を実装する！

可読性

  • プログラミングにおいて非常に重要

  • 言語が難しいことによって、様々なやり方が生まれてしまい、あとで何故コレが動くのかわからなくなる。

  • 言語がシンプルなら、書き方は絞られる。

  • 可読性は信頼性

  • 表現力が高いからといって、可読性が高いとは限らない。

  • 実装コストが高くなったり、パフォーマンスも予測しづらくなる。

正しい言語機能

  • 機能のための機能ではない
  • 目的を正しく認識し、必要な機能を

Goの目的

  • サーバソフトウェアを強力に作るためのもの

  • 各要素がそれぞれ単純に組み合わさっている

  • Gopherってシンプルだよね！(笑

単純さ

  • Goは実際には複雑だけど、シンプルにする仕組みがある
    • GC
    • goroutines
    • constant
    • interface
    • package

GC

  • 複雑さを隠す最たるもの
    • コレのお陰で、コードがシンプルに書ける
  • メモリの管理や、データのやり取りの厄介なことを隠蔽してくれる

並列性

  • プログラムを独立実行しているようにかける

    • goroutine
    • channel
    • select

  • goroutine

    • go function(arg)とかくだけ。シンプル
    • プログラマの考えることをぐっと減らしてくれる
      • スタックサイズがない
      • return, exit statusがない
      • 管理機構がない
      • IDを持っていない
    • スタック管理はGCに依存

定数

  • ただの数！！
    • 無限の精度整数型
    • 無限の浮動小数点型
    • etc...
  • 完璧にできてるわけではないが、かなり普通の数字のようになってる
  • こうすうるのはややこしかったけど、その代わりGoはシンプルになった

interface

  • メソッドの集合体
    • 想像以上に複雑

  • 型アサーションと型switchは本来の予定にはなかった

  • Goの最も特徴的な機能

    • io.Reader / io.Writerなどは、パイプのように扱えて、複雑さを隠蔽した

package

  • ライブラリ構成の設計
  • これの設計には非常に時間がかかった

まとめ

  • 単純さは設計が難しい
  • コレのために戦う価値がある

Goに入ってはGoに従え

  • うかいさん
  • Goの可読性について

Go Readability Approver

  • Go言語のReadabilityをレビューするチーム
    • より良いGo言語の書き方を教える
    • メインのプロジェクトではないコードを見る

Readabilityスキルとは

  • プログラミング言語のリテラシ

  • 言語ごとに作法が違う

    • C++ではプロジェクトごとに作法が違う。。。

  • 他の言語で考えると「この機能が足りない、書きにくい」となってしまう。

Goのコード

  • 明瞭・簡潔
  • 使いやすいAPI
  • 適切なコメント
  • 素直なコードフロー
    • goroutineなどのお陰で、コードの流れが読みやすくなる。
  • コードの実装を読むのに、Goの実装を読むのが一番理解しやすい。

優れたツール

  • ツールによるサポートを常に適用するカルチャー
    • go fmt
    • go vet
    • golint
    • godoc

ツールだけでは十分ではない

  • 読みやすいコード == 情報が認識しやすい/脳に負担がかからない
  • Goはシンプル

Readability Reviews

  • ミス・バグチェック
  • 見やすくレイアウトされているか
  • コードフローはわかりやすいか

  • APIはわかりやすいか

  • 気になってきた点を紹介

ミス/バグ

errorチェック

  • regex.Compileのerrorチェックを飛ばす人がいる

  • regex.MustCompileでエラーチェック

    • やっていいのは、初期化の時(varかinit())のみ

  • deferを使ったcloseのチェック

    • close自体もエラーチェックする

  • 値自体で-1がエラーみたいな判定をさせるのではなく、値とエラーを分ける。

    • error毎のデータを定義して、それを判定する

  • errorの設計

    • エラー処理の区別が不要なら、fmt.Errorfかerrors.Newで作って返す
      • err != nilでチェック
    • 色々情報を含めたい場合
      • structにエラー情報を含めて処理
    • panicは使わない
      • どうしても使いたいなら、packageの中にとどめて、recoverした上で外部にはerrorで返す

  • nil error

    • 値と型が共にnilの場合
    • 間違えやすいので注意

  • interface実装の型チェックには、structにinterfaceを実装するのではなく。。。

    • _ scan.Write =などのようにすることで、型チェックだけできる

見やすく

  • structフィールドのレイアアウト
    • 関連が深いものをブロックに分ける
  • 長い行
    • 長さ制限はないので、1行に
    • なので、名前は簡潔に
      • 与えられたコンテキストのなかで、わかり易い名前にする
      • 長い名前がわかりやすいわけじゃない
    • 冗長な名前をさける
      • レシーバ変数は数文字で良い

素直なコードフロー

  • 基本のコードパスのインデントは最小に

    • errorの分岐もシンプルに
    • funcを分割したり
    • if else並べるぐらいならswitch

  • time.Duration

    • constは型を持たないので、time.Durationにする型変換は不要

  • chanを使えば、sync.Mutex, sync.Condが不要な時がある

  • 型がわかっているようなときにreflectを使わない

テストコード

  • わかりやすいテストメセージ
  • 独自アサート関数を定義するより、言語の機能を使う
  • コメントにAPIの使い方を書くくらいなら、Exampleテスト

コメント

  • packageコメントを書く
    • mainパッケージは、コマンドのコメント
    • Exportしている名前にはコメントつける
    • 対象の名前を先頭に

  • コメントがわかりにくかったり書きにくい場合は、API設計を考えなおした方がいい

  • APIデザイン

    • 適切な名前のpackageを作る
  • APIをシンプルにする
    • 返り値は複数使えるので、出力変数としてポインタを使わない
    • Cとかでよくある
  • 非同期APIより同期API
    • chanをpackageを超えて使わない
    • 非同期化は使う側がgoroutine + chanで制御

読みやすいコードを書くには

  • 明瞭に表現すること

質問

  • 名前付き戻り値について、いつ使うか
    • コメントで補足しないとわからなくなるような場合(string, string, intなどのようになって、1つめ2つなんだっけ？としまう場合)
    • deferの中で、返り値を弄りたい場合などは、名前がついていないとそもそもいじれない

Gardner & Go

  • Tシャツ作ったよ
  • とあるゲームの色を。。。ｗ
  • FreeGuhoでEC販売してるよ
    • 1500 + 160だよ
  • Golang Tシャツもあるよ
    • 2500 + 160

App Engine for Golang Preformance

  • 普段はApp EngineでJava書いてる

App Engine for Go

  • 最初の呼び出し部分はmain()じゃない
  • init() -> http.HandleFunc("/", handler)とかしていく

App Engine for Goの微妙な所

  • Version upが遅い
  • GOMAXPROCS = 1限定
  • Goが本気出せない

Managed VMとは

  • Google Compute Engine上でApp Engineのコンテナを動かす事ができる
    • dockerで動いてる

  • GOMAXPROCSも挙げたりできる

    • 本気出せる

  • 微妙な点

    • deployが遅い
    • autoscaleの最小値が1
      • 常時課金発生

Performance

  • GAE
    • golang
      • 時間が経つと、何故か遅くなったのでちょっと要調査
    • Java
      • 最初からぐっと遅い
      • goの方がおねだん半分ぐらいで済みそう
  • Managed VM
    • 比較側のJavaがほぼ死んでる。。。
    • Betaなので。

Golang@ISUCON

なんでGo?

  • 改善効率の高さ

取り組んだこと

  • プロセスキャッシュ
  • タスク分散処理

プロセスキャッシュ

  • データをプロセス上に全て保持しておく

  • 永続化は適度なタイミングでRedisに保存したりする

  • グローバルに変数置いて。。。とかやると、Goroutine複数作ると整合性の保証が必要になる

  • Race Condition

  • syncパッケージ

    • 各種ロックを使う
    • sync.RWMutek
    • sync/atmic

  • atomic.Value

    • golang 1.4
    • プロセス上にatomicにデータ更新できるストア
    • シンプルにかける

タスクの分散処理

  • 画像・動画などは重複処理したくない

  • Task Queueing

    • goroutineとchannelでそのまま使える
    • goroutineの本数で調整できる

  • 重複処理

    • 1台の場合
      • sync.Cond
    • 複数台の場合
      • sync.Condを複数で
      • mcondつくった

  • 処理先を振り分ける

    • consistent hashライブラリ
    • stathat/consistent

mackerel-agent徹底解説

Mackerel

  • サーバ監視・管理ツール
  • エージェントがGo

mackerel-agentとは

ソースコード解説

  • 外部への依存: tomlを利用

  • windowsで動かなくなるオチを防ぐため、シグナルハンドルではos.Interruptを使う

  • chan chan

    • チャンネルでチャンネルを渡す
    • 複雑なので、シグナルハンドルもメイン処理に入れたほうがいいんじゃないか？というのはある

  • loopの状態管理

    • enumっぽくtype作って処理

  • なんか色々改善点あればご指摘ください

Why my Go program is slow?

  • methaneさん
  • CPUプロファイラの話

runtime/pprof

  • サンプリングプロファイラ
    • モンテカルロ法に似てるやり方だよ
    • 計測方法として、実行時のサンプルを大量にとって、重い箇所を特定する

  • net/http/pprofなんかがHTTPではおすすめ

  • 解析するプログラムもpprofという名前

  • Go 1.3からCLIにbundle(Perl版)

  • Go 1.4からはGo版になってる
    • ぐっと便利になってるので、ここだけでも1.4にするといいよ

デモ

  • webで展開できたり、アセンブリ単位で見れたりしてすごい

どこが重いか

  • GC
  • memory copy
  • function call

GC

  • GOGC=400とかすると、急激な負荷に唐突に突っ込むとGC頑張っちゃって負荷が高くなってしまうので、それを遅くする

memory copy

  • 文字列便利だからってコピーしまくると大変
  • []byteとか使おう

function call

Golang JP Community

  • 日本のGolang JPのコミュニティの紹介

Go at Gengo

  • Gengoの中の人
  • 中でめっちゃ使ってる

the early days

  • GoShip

    • Goベースのデプロイメントツール
    • なぜGoを使った？
      • productionに入れる前に、試しに作ってみるのに調度良かった

  • Go API

    • シンプルなPHP(CodeIgniter)のエンドポイントを持っていたが、これをGOに移植した
    • 500 ms -> 10ms になった
    • 今では78%のAPIがGoに置き換わった

  • どこから入れるべきか

    • まず、クリティカルじゃない所から入れよう
    • 全てを一度にrewriteしようとしないほうがいいよ

Dive in

  • Managing dependencies

    • まず試したのはここら
      • go get
      • gom
      • godep
    • 結局シンプルなshellscriptになった
      • godepが標準ぽいけど。

  • Test Fixtures

    • reflectをつかって頑張ってる
    • Gorpの｀Insertable`を使うと簡単にできる
    • LoadFisturesみたいなの定義して使ってる
    • ただ、fixtureテストが並列化できないよね
      • go test -p 1してる。。

  • Quick Wins

    • graceful shutdownの例
    • gofmt -s / gofmt -w は走らせよう
    • go test -race / go importsしよう
    • go vet 大事

One Year Down

  • 抱えてる問題
    • logging
    • slow build times
    • test fixtures

NSQ-Centric Archtecture

chatサーバをGoで

  • Go + webview + websocket

NSQ

  • message queue
  • SPOFなしでスケーラブル

  • プッシュ型のメッセージ通知

    • データフォーマットはなんでも良い

  • 問題点

    • メッセージが1回以上とどく
    • 順序保証がない

  • NSQのアーキテクチャの話

  • 自作したChatアプリのアーキテクチャの話

  • 面白そうだけど。。。話が飛んじゃって流れがわかんなくなった。。。

Hacking Go Compiler Internals

  • moriyoshi

対象の人

  • Go に拡張いれたいなー、コンパイラーどうなってんのかなーって人

Lexer

  • Goのコードをより抽象的なデータ構造に変換する

  • どういう時にLexerを弄りたいか

  • UTF-8の関数怒られた(寿司)

  • これを追加したい！
  • なんてことをやってみた

Parser

  • Lexerが作ったTokenを抽象構文木(AST)に変換する

  • yaccで作られてるよ

  • Braket operator overloadの例

  • print()関数はdebugの時に便利だよ

    • printfっぽいやつ

Roll-up

  • 一見大変そうだけど、中身は凄くシンプルでhackしやすいよ！

nginx-build

  • bokkoさん
  • mercariのひと

本題

  • Go製のnginxビルドツール

  • nginxのビルドするのがつかれたので、作った

  • nginxのビルドは、現実的にはいろいろなものをダウンロードしてきたりしないといけない

  • configure optionsを大量に追加しないといけない

  • しかもそのビルドスクリプトをメンテしないといけない

  • これらまとめて解決してくれる

使い方

  • binary を持ってきて、mkdir work -> nginx-build -d work みたいにする
  • 3rd partyモジュールを、iniファイルに指定しておくと、まとめてダウンロードしてくれる

なんでGoで？

  • Go好きなので
    • 並列ダウンロードが楽
    • CLIツールを書くのにすごく適してる

Terraformで始めるGo言語

楽天のInfrastracture as Code

  • サービスいっぱい = サーバの種類が多い
  • 最下部のインフラ層に向いてそうなterraformがリリースされたので使ってみた

Terraform

TerraformとGo

  • Terraform Plugin開発

  • v2.0からフレームワーク機能をサポート

  • やりやすいから、このへんから始めてみては。

Goでビルドパイプラインツールを書いた話

なんでGo?

  • ジョブの実行をgoroutineで
  • データの受け渡しをするのにchannel
  • このへんが扱いやすそうだったので

その他Tips

  • プロジェクト構成について

    • coreos/etcd を参考にした
    • テスト、ビルドはshell

  • package管理

    • submoduleでやってたけど辛かった
    • Godep

  • ログ出力

    • どこも軒並み自前で用意してた
    • golang/glogを利用

Goの所感

  • Object指向的な書き方をしてしまって、ぎこちない感じになった
  • channelをつかってみた、厳しくなったらsync.Mutex

go/parser go/astの話

I/Oに依存したテスト

I/Oに依存したテストをどうするか

  • RubyだとStringIO
  • Goでは、bytes.Buffer がある

bytes.Buffer

  • []byteにいろいろメソッドが生えた感じ

  • io.ReadWriter

  • テストコードの実践

ポイント

  • I/O依存部分を切り出す

  • インターフェースに依存して書く

  • ここまでー

Destributed system

  • marioさん
  • 分散システムの話

Consul

  • 実装の例の話