読者です 読者をやめる 読者になる 読者になる

てくすた

ピクスタ株式会社のエンジニア・デザイナーがつづるよもやまテクニカルブログです

デザイナーが人生で初めて登壇した話

皆さん、こんにちは。 PIXTAの悩めるデザイナー、たかせです。 Nintendo Switchおもしろそうですね。 買うべきか、今は待つべきか。。。

先日「みんなのウェディング」さんのデザイナーの方々と合同で勉強会を開催しました。 この勉強会では、「インハウスデザイナーの面白さ&タイヘンなこと」をテーマに、PIXTAとみんなのウェディングのデザイナーの方々が発表しました。

そこで、人生で初めて発表する機会をいただいたので紹介します!

準備

発表内容

自分は以前、受託制作の業務をしていましたが、2016年9月からPIXTAのインハウスデザイナーになりました。 そのとき、受託制作とインハウスデザイナーの作業内容の違いに困惑することがたくさんありました。 そこで発表では、困惑したことについての対処方法を紹介しようと考えました。 今後インハウスデザイナーになりたい人や、中途入社のデザイナーの教育、フォローアップに役立てていただけると思っています。 f:id:kazunori-takase:20170329105638j:plain

前日

資料作成と発表練習

発表資料はそこまで苦労せずにまとめることができました。 しかし、同僚に発表をきいてもらったとき、思っているようにはできませんでした。 その原因は、自分の考えを話すことが少なく言葉が出てこなかったことと、資料がまとめきれていなく不十分だったことだと感じました。

精神と時の部屋(ただの会議室)を1時間ほど借りて、大慌てで資料の修正やカンペの作成、時間を計測した練習をしました。

当日

業務時間中

今回の会場はPIXTAのカフェスペースで、完全にホームゲームでした。 しかし、もともと緊張するタイプで、発表は19時半からでしたが、昼過ぎから緊張していました。 緊張して発表内容が頭に入りそうにないので、午後に予定されていた会議を週明けにずらしてもらいました。

発表中!

会議をずらしてもらったおかげで発表内容をしっかり記憶できたため、言葉に詰まることなく、時間も予定通りに発表できました! さらに、イベントに参加してくれた方々を意識して、目を見て話すこともできました。 しかし、スクリーンで資料を表示していて部屋が暗かったため、カンペは役に立ちませんでした。 f:id:kazunori-takase:20170329105920p:plain

懇親会中

発表やパネルディスカッションが終わったあと、お酒やピザなどの軽食もある懇親会を開催しました。 今回はデザイナーのあるある苦労話をしたので、懇親会も非常に盛り上がりました! イベントに参加してくれた方々も「自分も同じような苦労をしていて・・・」と話ができ、すんなりと打ち解けられて良かったです。

感想

資料については、実例を加えることができず、デザイナー以外の方々にはわかりにくい内容だったかもしれません。 発表については、もう少しUIデザインの成功談、失敗談など、具体的な話をすればよかったと思いました。 そして、聞いていただいてる方々の反応を見て、笑い話にしたり、真面目に話したりと、内容を変えていけたらいいな、とも思いました。 f:id:kazunori-takase:20170329105654j:plain

次回の発表について

今回はデザイナーのあるある話をしましたが、次回はUIについて少し掘り下げた話をしたいです。 また、自分が学生時代、絵画を学んできたので「有名絵画から見るUIデザイン」でも語ってみたいです。

PIXTAにおけるCloudSearchのコスト削減

こんにちは、ピクスタ開発部の星直史です。

先日開催されたJAWS DAYS 2017でLT登壇してきたのですが、時間の制約上、めちゃくちゃ早口だったので、テキストベースでも解説します。

目次

  • 背景
  • CloudSearchの料金体系
  • コスト圧迫の原因と対策
  • コスト削減結果

背景

現在PIXTAでは2,200万点以上の素材を販売をしています。*1
素材は、クリエイターさんからアップロードする際にタグ付けを行い、そのデータをCloudSearchに格納し、検索に使用しています。
また、PIXTAでは、日本語の他に、英語繁体字簡体字タイ語と多言語対応しています。
そのため、CloudSearchに格納するタグ情報は各ロケールに合わせて、翻訳したタグ情報も格納しています。

2,200万点以上のデータが5言語分存在し、それぞれに、シノニム、表記揺れ、ステミング情報が格納されているので、コスト削減前は、CloudSearchのインスタンス数が膨れ上がってしまっていました。

f:id:watasihasitujidesu:20170313121428p:plain

今回は、その膨れ上がるインスタンス数をどのようにして抑えたかについての話です。

料金体系

CloudSearchの料金体系

まず、敵を知るべく、CloudSearchの料金体系を確認します。

料金表

課金項目は下記の通りです。 公式にもありますが、項目名とどんなときに課金されるのかのサマリです。*2

課金項目 内容
検索インスタンス インスタンスタイプによる1時間あたりの料金 * PartitionCount * ReplicationCount
ドキュメントバッチアップロード CLoudSearchにデータを格納する時に課金。
IndexDocumentsリクエスト スキーマなどを変更し、インデックス再構築をした際に課金発生。総データ容量に対して、1GBあたり0.98USD。
データ転送 データ転送のアウトについて課金。同一リージョン内は無料。

PIXTAにおける支払い内訳

上記の4つの課金項目を基に、どこにコストが多く発生しているかを特定します。

内訳のこの通りです。

f:id:watasihasitujidesu:20170313121447p:plain

一目でわかりますね。あいつです。PartitionCountがコスト圧迫の要因だとわかりました。

コスト圧迫の原因と対策

では、PartitionCountがなぜ、あんなに必要だったのかを深掘りしていきます。

インスタンス数は何によって決まるか

インスタンス数は、スケーリングによって決まります。内容は、ReplicationCountとPartitionCountによって決まります。

項目 内容
ReplicationCount トラフィックとレイテンシに影響を与える。Count数が多いと、多くのトラフィックを捌くことができ、レイテンシを低くさせる要因の一つになる。*3
PartitionCount ドメインに格納されるデータセットの総容量に依存。格納するデータが増えれば増えるほど、Partitionが必要になってくる。

したがって、今回PartitionCountが多いのは、データセットの総データ容量が大きいのが、原因だとわかります。

インスタンス数を減らすには

もう一段深掘りするために、データ容量が増える原因について見ていきます。 ここを知る & 解決することが、今回のメインとなります。

データ容量は下記3つに起因します。

  1. フィールド数が多い
  2. フィールド内のデータが大きい*4
  3. フィールドに設定している検索Optionが多い

また、これらの設定はマネジメントコンソールのサイドナビにあるIndexingOptionsから確認できます。

フィールド数が多い

f:id:watasihasitujidesu:20170313121505p:plain

当時、社内の検索機能のドメイン知識について、共有するものが足りなかったり、職人(!)による作業が多く、このフィールド消していいの?なにこれ怖い。みたいな状態になっていました。
そして、実際には使われていないフィールドが多く存在していました。

なので、まずは不要なフィールドの削除から始めました。

フィールドに設定している検索Optionが多い

f:id:watasihasitujidesu:20170313121517p:plain

次に疑うべきは検索Optionの最適化です。
検索オプションは、フィールドごとに、下記機能の使用可否を選択できます。

  • 検索対象とするか
  • ファセットを用意するか
  • 返却値としてしようするか
  • ソート対象とするか
  • ハイライトするか

詳細は公式ドキュメントが参考になります。

図を見るとわかるのですが、コスト削減前は、オプション全てにチェックが入っていました。
こちらは、検索オプションの意味や使用箇所も深く理解できていないまま、とりあえず全部チェックしてしまえ!状態だったので、一つずつ見直していくことにしました。

IndexingOptionsとIndexSizeについて補足

IndexingOptionsとインデックスサイズの関係については Amazon CloudSearch Deep Dive and Best Practices | AWS re:Invent 2014の25スライド目「Effect of options on index size」がとても参考になりました。

資料の例だと、6KBのドキュメントが2,500万件登録されていた場合に、
オプションを全くつけていない場合と、全てのオプションつけていた場合では、インデックスサイズが243%も増加していることの説明をしています。

コスト削減結果

f:id:watasihasitujidesu:20170313121529p:plain

ここまで説明した内容を実施した結果、Index再構築直後は上記のような結果になりました。 対応前は、使用率が70%台だったのに対し、対応後は30%台になりました。 コストが半分近くになったことがわかります。

まとめ

今回のコスト削減に関しては、テクニカルことは全く必要としませんでした。 それよりも

  • まずは、どんな課金体系なのか敵を知ること、
  • そして、何にいくらくらいかかっていることを知ること、
  • 最後に、何故、コストがかかっているかを知ること

これらを地道に調べることで、無駄なコストが省けたのだと思います。

ピクスタでは一緒に働くメンバーを募集しています!

*1:20107/03/13時点

*2:詳細は公式に譲ります

*3:レイテンシはネットワーク、クエリの複雑度など、多くの要素に左右されるので、ReplicationCountを増やしといって、爆速になるわけではない。

*4:今回ここについては、言及しません