AWS Summit 2015 - Day1 - デベロッパーが切り拓く、次の時代
プラットフォームの変遷
- 5年スパンぐらいで、なにか起きている感じ
- また今年辺り、なにか新しいムーブメントが来るのでは
テーマ１: 外部環境が変わる中で、変わったこと、変わらなかったこと
変化の最初の頃ってわからない
- EC2が最初話に上がった時、凄さがわからなかった
- iPhoneで、最初誰がネットするんだって感じだった
今クラウド全盛だが、５年後ぐらいには違うことが起こっている
その時はやっているものに安住しないようにする
一番変わったことはなんですか？
変わらない所
やってる時はシンプルなのは不安だし厳しい
- 色々やってると、もっとしっかりした仕様が必要では？と迷うことも
- ただ、実際にはUnixの哲学のようなものが勝つ
テーマ２: 技術を取捨選択した際の大原則・考え方は？
オープンな方を選択してきた
- それが正解かはわからない
テーマを否定するようだが、技術は手段でしか無い
- 技術選択の善し悪しによって、キャリアを築いてくという考え方自体が危うい
- OSSはコミュニティとしてやっていく、というトレンドだからそうしただけ
- それは単純に流儀に乗っただけ
問題を設定して、それを解決するための技術を選択する、というのがあり方
- 選択するのは結構怖くて、ブログに書いて一晩たったらなんかあれれ？ということもある
- メインストリームからみて「おもちゃ」と言われるようなモノを選んでやってったところはある
課題が先にあるか？それとも、おもちゃとして触ってみる感じが強いか？
- やはり課題ベースで触ることが強い
- 興味ベースで触ることもあるが、今やっている仕事の中で何かしら課題が前提としてあるからやってる
- なんの課題もなく触ることはない
自分で問題設定を生み出せる人なんて起業しちゃえばいい、という気持ち(おおばさん)
- 会社にいるのは、問題が常に降ってくるから
技術から出発する、というのは非常に危険だと思っている(伊藤さん)
- この技術ではここまでしかできない、という制限が発生してイノベーションは起きない
- たとえば、デザイナーが先にプロダクトをデザインして、無茶なものを試行錯誤しながら何とかすると素晴らしい物が出来る、ということもある
世の中の大発明みたいなものは、好奇心から生まれるということもある
- 電気とか。最初は皆どうしていいかわからない
- ただ、僕らがやってるのはビジネス。そこは違う
これからの外部環境の変化を、どう迎え撃てばいいか？
- 個人としてどうすればいいか？
チームとしてどうするか？
マネジメントの話(伊藤さん)
- スタートアップだと、曖昧さに対する耐性が高いか低いか、というのが重要になる
- 最初にもやっとしたものを渡されて、徐々に形を作っていく
- モヤモヤした中を皆で突き進んで作っていく
- いい感じのPMがこっちだ！といって引っ張っていってくれるわけではない
- そういう状態でも進めていける人と一緒だと、やりやすい
そもそも変化を受け入れられる、という事が前提(大場さん)
- 開発にかぎらずビジネスを考える
- 開発部門、というかたちで区切ってしまったら、全員がビジネスのゴールを見るのが難しくなってしまった。
- そのため、企画とエンジニアの枠組みを切り離し、各チームにばら撒くようにしてみた
ビジネスのゴールでも、やはり同じ話で、責任を区切るべきではない
- そうやってエンジニアだから、という責任境界を区切らずに、モヤモヤした中でやることを見つけていける力が必要
いちデベロッパーとしてはどうか？
- 年齢の問題もあるが。。。
- 新しいテクノロジーが出てきた時に、一つにフォーカスしていくのは危うい
- 新しいテクノロジーを牽引していくのは、やはり若い人のやること
まとめ
- 最後に一言
- 業界狭いので、その時時に全力でやってくしかないのでは(大場さん)
- 転職を一番最初に意識したのは、「我々データセンターのプロなんだから、本屋(Amazon)なんかに負けるな」という上司の言葉
- 鼓舞したかったんだろうが、現実が見えてない
- 現実を把握して、その状況を見てやっていく
- 転職を一番最初に意識したのは、「我々データセンターのプロなんだから、本屋(Amazon)なんかに負けるな」という上司の言葉
- 正解がわからないから、いろんな人の話を聞きたくて皆カンファレンスに来てるのだろうが。。。(伊藤さん)
- そんなのはこっちもわからない
- 正解はわからなくていいんだけど、先行ってるのがどれくらいのポジションで、自分がどんな位置にいるのか
- トップと自分とのギャップを把握するのは大事
- 業界狭いので、その時時に全力でやってくしかないのでは(大場さん)
AWS Summit 2015 - Day1 - Redshift Deep Dive
Redshiftの概要
LeaderNodeと並列のComputeNode
超並列演算
- CPU / disk /network /ioの並列化
データの格納
- 列思考(カラムナ)
各CPUコアにプロセスを張り付けていくような形で実行していく
- ノードスライス
データのロード
- COPYコマンドを実行すると、S3から直接ComputeがCSVファイルを引っ張ってくる
- ファイル数はスロットの倍が望ましい
Redshiftの主要アップデート
カスタムドライバ
- Redshift用ネイティブドライバが出た
- PostgreSQLのドライバよりも、パフォーマンス、信頼性が高い
Interleaved Sort Key
- Sort Keyを複数のカラムで指定可能になった
- それぞれのキーがフェアに扱われるようにデータが格納される
インテグレーション
データ連携をどうするか
オンプレミスとのデータ連携
- S3に一旦CSVをアップロード
- オンプレミスからRedshiftへの直接insertは推奨していない
- 不可が高い場合はDynamoなどを一旦挟んでからRedShiftへ
AWSサービス間のデータ連携
- S3がハブとなり、他のサービスと連携
- Data Pipeline
- Kinesis
- Lambda
サンプルシナリオ
- シナリオ
- RDBMSから抽出
- S3へアップ
- EMRに変換
- Redshiftにロード
バッチ
- Talendというツールを使ってみた
- 一旦S3にアップロード
- EMRに流してフィルタリング
結果をRedShiftへ
Talend
Extract
- CSVファイルとしてレコードを抽出
この時点で複数ファイルに分割
Change Data Capture - CDC
ポイント
- 大量レコードの場合は、メモリの枯渇を防ぐためにカーソルを利用
- 抽出後、圧縮すればアップロード時のコスト削減
- ファイル分割数は、スロットの倍に
Upload
- S3に並列アップロード
転送時間が短縮できる
ポイント
- Uploadの並列度は、クライアント側のCPUスペックを考慮
- S３のキー(先頭４文字)をランダム化するのが理想
Transform
どこで実行するか？
Amazon EMR
ポイント
Load
- Redshiftへのロード
ファイル一覧や正規表現に寄るCOPYコマンドを指定したり
ロードに失敗したレコードは
stl_load_errorsに格納MAX_LOAD_ERRORを指定し、一定回数のエラーは無視
ポイント
- ロード時にテーブルロックがかかるので、アクセス頻度が低いタイミングを狙う
- ロード先のテーブルを本番テーブルと差し替えたり
- INSERT ~ SELECT はCOPYと同様にコンピュートノードで並列処理されるので効率が良い
- ロード時にテーブルロックがかかるので、アクセス頻度が低いタイミングを狙う
まとめ
AWS Summit 2015 - Day1 - Aurora Deep Dive
- AWS 星野さん
Auroraについて
- RDSの5番目のエンジン
- クラウド時代に特化した新しいDBエンジン
previewだが、5/20からproduction環境に移行
料金体系
- R3シリーズのみの提供
- ライセンス料は不要
- MySQLとのコンパチブルを保つ
- ロックインはない
特徴
なぜデータベースを再考したか
モノリシックなDB
- 複数の機能レイヤーが１つのアプリケーションになっている
- スケールアウトする場合、このセットで増やす必要がある
- コスト・可用性・柔軟性の問題
今、再実装するならどうなるか？
- 1970年代の方法では実装しない
- スケールアウトが簡単で、セルフヒーリングなもの
- AWSと簡単に連携したい
これをフルマネージドで提供する
アーキテクチャ
- ログレイヤ
ストレージレイヤ
- バックにスケールするストレージサービスを採用
- EC2 / Dynamo / SWF などを管理コンポーネントに採用
キャッシュレイヤの分離
- キャッシュをDBプロセスの外に置いた
- DBを再起動しても、キャッシュが残る
ストレージ
リードレプリカも同じストレージを参照
- 壊れた場合も再ストレイピング、ミラーの修復なども自動で走る
Log Structured Storage
- 追記型のストレージシステム
- 常に末尾にデータ追加
- GC
- 新規データは末尾に追記
- これが10GBのチャンクごとに書き込みが行われる
- 追記型のストレージシステム
ディスク障害検知
- 2つのコピーに障害があっても読み書き可能
- 3つ障害があっても読込は可能
- 自動検知して修復
-
- Binlogによるレプリケーションではない
- 同一のディスクを見ている
- マスターの負荷を最小限にしつつ、15台のリードレプリカを作成可能
- 同じデータのディスクを参照しているので、フェイルオーバーしてもデータロスがない
- Binlogによるレプリケーションではない
セキュリティ
- データの暗号化
- SSL
- 直接ログインは不可
DBクラスタ
- DBクラスタという概念を持っている
- マスタとリードレプリカ
- DB Parameter Group / Cluster Parameter Group
- DBクラスタという概念を持っている
新しいメトリクス画面
- キャッシュ・CPU使用率についてわかりやすくなる
フェイルオーバーとリプレース
- リードレプリカがある場合は1分程度でフェイルオーバー可能
- 優先的にフェイルオーバーさせるノードを指定可能
- ノードリプレース時の起動先AZを指定可能
クラスタエンドポイント
- WriterのCNAMEになっていて、壊れたら別の新しいノードに切り替わる
- Readerはそうはなっていないので、アプリケーションで対応
高速なデータ修復
- 並列、分散、非同期で行われる
Streaming snapshotとPITR
- バックアップを残す期間を指定可能
- 任意の時間に秒単位で戻すことが可能
- 現在では、2分前のデータから可能
SQLによるフェイルオーバーのテスト
- 擬似的に障害をシミュレート
パフォーマンスを引き出すために
- クエリ並列度が高い、データサイズが大きいケースで効果を発揮
ロックやQuery Cacheに手を入れて、性能を向上
CPU利用率はMySQLに比べて効率化
パフォーマンス
-
- MyISAMのテーブルは無いのでコンバートされる。1.5TB異常な以下は確認
Auroraの使いドコロ
AWS Summit 2015 - Day1 - Amazon CloudSearch Deep Dive
- 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が反映されないことがある
１ノードでまかないきれなくなったら、スケールアウト
検索ドメインの変更など
- 同様にEMRで
初期のデータを投入する場合
大量のリクエストに備えて事前対応
導入事例
schoo
- 爆速で導入
- リリースまで1週間
nanapi
- デフォルトのまま使ってる
- それでもいい感じに検索できている
Chatwork
- 日本最大級の利用例
- 5億件以上のデータ
- 運用はほぼメンテナンスフリー
- CloudSearchにして速度はかなり改善した
更に知りたい方に
- DocValues
- CloudSearch SAのビデオ
- たとえば、普通のqとfq(filter query)の性能差とか
AWS Summit 2015 - Day1 - keynote
Keynote のメモ
AWS Japan CEO 長崎さん
昔Jeffが書いたメモ
- 低コスト構造を作り、それをローコスト化につなげることで、顧客満足度が高まる
- この構造がアマゾンのモデル
スケール、スピード、イノベーション
-
- 店舗がないので、テクノロジーが命
- サーバが間に合わない、などは命取り
- 顧客の価値にフォーカスしろ！
- 社内調査した所、開発者の時間のほとんどが、サーバのおもりに費やされていた
- ビジネスをより早く
- ワンクリックでサーバの準備が出来るようにし、インフラをプログラマブルにすることで価値にフォーカスできる
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名の会社
どうつかっているか？
Speed
- Flexbility
Fanctionality
キャンペーン等のトラフィックが予想できない場合に有効
- 同時にpush通知を送る場合
- 秒間に14000に送れる
長崎さん
- 素早いプロビジョン
それをすぐに縮退できるか
コアなサービス部分
既存の資産を容易にするサービス群
Gartner
実際の業務のサイズ・形は千差万別
ニーズに合ったプラットフォームを用意することで、これを解決してきた
共有ファイルシステムの課題
９年の運用実績
- 既存の資産を運用するのとは、全く違う規模感
データの収集・保管・分析・共有はとても困難だった
機械学習を利用する顧客が急増中
- Amazonは元々レコメンデーションで機械学習を利用
これをもっと社内で活用できないか？
Amazon Machine Learning
- フルマネージド型機械学習サービス
- ハードウェアも気にしなくて良い
Aurora
Amazon WorkSpaces
- ソフト・ハードの管理不要
- 様々なデバイスからアクセス可能
- 月額利用オンプレより半分の価格
Amazon ECS
Amazon Lambda
- コンピューティングリソースを極小化
- イベントをトリガーにコンピュータを起動
- そのイベントの時間しか課金されない
- 今までだと、インスタンス単位での課金(1h)だった
- 100msならその分だけ
第三者認証と監査により証明された、高いセキュリティ基準と運用基準
ファーストリテイリング CIO 玉置さん
売上高1兆3800億円！
作るシステムは最初からグローバル
- 直感的に、マニュアルいらずでどのデバイスでも動く
スピードに応えるクラウド
なぜAWS?
- 重視しているのは、Large Community
- エンジニア・デベロッパーを惹きつけて、自発的なエコシステムを作る魅力がある
- ここに非常に魅力を感じている
瞬間で、11万リクエスト/sec
正直、サイジングがきちんとあたった覚えが殆ど無い
そんなものよりAWSのスケーリングにかけている
マルチリージョン
Now Hiring!
長崎さん
- 「重力」には逆らえない
- 変化や未知のものはだれでも怖い
画像変換Nightに行ってきた
- http://connpass.com/event/11516/
- とりあえず、見つかった限りのスライドは載せました。
- 発表者のみなさま、会場のGREEさん、ありがとうございましたm( )m
感想・まとめ
- 全体的に濃い話だった
- go-thumber使ってみたい
- 基本的にみんなImageMagick大好き
- というか、あまり他に優秀なインターフェースがないんだな、の印象
- yoyaさんは神
- 自力でやりました、という話が中心で、こうやって楽にやってますという話はなかった
- 切り出しとか考えると、ASPつらいのかもね
- でもCloudinaryすごいよ？
- ImageHayabusaへの期待感すごい
サムネイルマスタとgo-thumber
- はるかさんさん
pixivのひと
オリジナル画像をそのまま配信
- 転送量がめちゃ多い
- デザイン大変
- 後からサムネイル作るの大変
- サービスが大きくなるにつれ、つらくなる
アップロード時にサムネイル生成
- アップロード処理が大変
- 非同期処理必要になる
- そうしないと待たせちゃう
- サイズ変更が大変
- アップロード処理が大変
リクエスト時にサムネイル生成
- 動的変換
- デザイン変更が簡単
- キャッシュしてくれればリクエストも少ない
動的生成で困ること
- 生成元画像に依存
- サイズもバラバラでメモリ量もバラバラ
- 処理が面倒
- フォーマットの問題
- 加工とかとか。。。
- 生成元画像に依存
サムネイルマスタ
- サムネイル生成元となる画像マスタ
- リクエスト時の生成の負荷を軽減
- 他のサムネイルよりでかい
- 長年培われたcrop技術により。。。縦長は下が切られる
画像はJPEG保存
-
- ブラウザによってICCプロファイルを解釈したりしなかったり
どうすればよいのか
- カラーマネジメントできるエンジニアが不在
- ユーザー環境がただしいプロファイルを扱っているかわからない
これらの問題をサムネイルマスタで解決
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で特定のものだけ通してる
- 開発環境ではフリーに通してる
- A: nginxのrewriteで特定のものだけ通してる
実践ngx_small_light入門
- bokkoさん
Mercari, Inc.
ngx_small_light- Imagemagick / imlib2 / GD
- PNG / JPEG / GIF / WebP
setup / install / 設定
small_light on;small_light_pattern_defineで名前を付けられる基本的なパラメータ
- dw,dh
- of
- q
- p
- e (defaultはImageMagick)
small_light_getparam_mode on;- query stringから指定できる
- デフォルト off
- 設定すると
small_light関数は使えなくなる
S3にある画像を
ngx_small_lightでリサイズ- リゾルバの設定が抜けてた
画像ライブラリの比較
- それぞれ特色ある
その他のモジュールについて
mod_small_lightngx_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
- OpenMP
- WebP
- JPEG / PNGと比べて軽量
- ImageMagickとGDで使える
- 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はぶっ壊れてる
ChangeLogを追う
- 6.8.6-8まで。。。
ImageMagickのバージョンアップ怖すぎ問題
- 絶対避けたいこと
- ImageMagickのバージョンアップで画像の色味が変わってしまうこと
- 全てをチェックするのは無理
yoyaさんに相談
- 6.8.7からは色空間の扱いが変わった
- ここで色味が変わる可能性がある
- 6.8.7からは色空間の扱いが変わった
WebPにはどのバージョンを使えばいいか
- 6.8.6-8まで上げれば、必要十分
- 6.8.7からは色味が変わる可能性がある
- これから使う人は、最新を。
- 6.8.6-8まで上げれば、必要十分
ImageMagickアレコレ
- http://diary.awm.jp/~yoya/data/2015/02/18/ImageMagick-something.pdf
- yoya
今回はImageMagick 6だが、本家は既に7前提
6と7の違い
- ディレクトリ名が違うだけ。。。
ImageMagickってなんだっけ
- 画像を処理できる何か
- コマンドがある
- いろんな言語から使える
- フォーマットがたくさん
- 100種類以上のマイナーなものまで
- cssのinlineフォーマットまで対応してる
ImageMagickの開発傾向
- 活発すぎる
- APIのバイナリ互換とか気にしない
- コレに切れてforkしたのがGraphicsMagick
バージョン毎に声質が違う
- 全バージョンをそろえるｗｗｗ
- 600ぐらいビルドｗ
全バージョンで実行
QuantumDepth
- Q8/Q16
- RGBの各値を8bit/16bitのどっちで持つか
- 普通の人間の目なら8bitで十分
- ImageMagickはデフォルトQ16
Q8の問題点
- 医療用画像などではQ16なので使えない
- HDR等のフィルタでちょっと荒くなる
OpenMPが重い
JPEG画像変換
- 何故JPEGHintが早いのか
最近のトピック
- 6.8.7-4がエポックメイキング
- 6.8.8-2
- icoファイルをauto-resizeできるように
6.9.0-4
GIFアニメ最適化
- 変化のある部分を切り出して、透明にして軽量化
GraphicsMagickは？
- GIFアニメ生成が早いのは、実は単にエンジンが古いだけ
- GraphicsMagicはQ8デフォルトなので、比較するなら同一にしないとアンフェア
ImageMagickを弄りたくなった人へ
- Cristyさんはコミットコメントを書かないｗ
- コードはきれいなので、意図は伝わる。。。
RICOH THETAの全天球画像でペーパークラフト
- ちはやふるさん
全天球画像をつくる
RICOH THETAの静止画保存形式を切り取り、印刷
- iOSアプリ PazuCraft
- ペーパークラフトになるの面白い！
1px interpolation
https://docs.google.com/presentation/d/1R4htUndRQonOeTg35t17J8Lw4hWiHje0fWtm1xdIkds/edit#slide=id.p
Greeのひと
宮崎さん
- JS書いてる
1px interpolation
- 1pxの線を描画する際に、レンダラがどのドットに割り当てるか悩んで憤死するｗ
- ブラウザのバグ
再現方法
とある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異常に高負荷になる
- WebPの変換がおかしい
JPEGのDCTブロックでコンテンツ指向のトリミング
4_sukeさんコンテンツの場所を考慮して切り取ってくれたらいいのに！
-
- 顔認識の結果をベースとしているらしい
- 顔認識は計算リソース必要
- 保存するとしても、ストレージ必要
- 顔以外は認識してくれない
JPEGエンコーダに手を加えればいいんじゃね？
- DCTブロックを直接参照すれば！
JPEGデコードの過程でDCT変換したデータが得られる
- 高周波成分が集まってるところが、経験則的には中心ぽくなる
ハフマン展開 + 逆コサイン変換を DCT変換の後に追加
- 人がたくさん入ってくると、平均化されて真ん中が切り抜かれがち
まとめ
- ナマの画像にそのまま使うので、計算量が少ない
- 追加実装も少ない
- 顔認証と違い、なんでも大丈夫
- JPEGにしか適用できない
- 文字が入ってると弱い
jpgjsに手を入れた
pixiv方式とどちらがいいか？
- どれだけコンテンツに対する仮定を置くか
- 何がメインか、によって違う
- 仮定を踏まえて定量評価するしかない
ImageHayabusa
Guntherさん
デザイン作業効率化
- 素材の切り出しや必要な素材サイズを毎回デザイナーにお願いしないといけない
- これを一発で
メリット
- 作業が楽になる
パラメータで様々な変換ができる
- PSDの特定のレイヤーを指定して書き出しもできる
初回は生成、２回目以降はキャッシュ
- CSSも出力し、中で使っているフォントもわかる
8086命令セットの細かいメモ(2)
今日もまた、細かいけどためになる話を教えてもらったのでメモ。 自分で事後補足として調べたものも含むので、用語が正確じゃないかも。ツッコミ希望。
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フラグは、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の進化・効率化と互換性確保のバランスを綱渡りしてる感じが垣間見えて、非常に面白い。
全命令セットを実装していくのは冗長な作業では、と最初は思ったけど、このへんを知るにつけ意味のある作業だと実感が強まってて良い。
