投稿者「Martin」のアーカイブ

私はデジタルノマドです。世界中を旅しながらソフトエンジニアとして働いています。

Martin|2017年12月25日
DevOps

日本語訳は後半に掲載しています :)

I am digital nomad. I work as software engineer while traveling around the world.

Yes, it is true! I work as software engineer for Quant (Lancers spin up) during my travel into foreign countries. I love software engineering and adventure, so I shaped my life to do both.

It was 5 months ago on Friday, I showed in Shibuya office for the last time. No, I did not ‘graduate’, I evolved. I spent Saturday packing my backpack because Sunday was the day of my flight to Bali.

“Passport? Have! Flight ticket? Have! Laptop? Have! Laptop charger? Have! Mouse? Have! External keyboard? Have! Mini Wi-Fi router? Have! Swimming shorts? Yes!”.

Next Monday, I woke up in Ubud, art centre of Bali. Then I opened my laptop, connected to wifi, went to company chat and typed ”おはようございます”. It was 9:00 JST (Japan Standard Time).

My company allowed me to work remotely, I do not need to sit in the office to do my work. Working remotely does not mean you have to be as extreme as me with my Digital nomad lifestyle experiment. Remote position allows me to choose place where I want to work from. It could be at starbucks next to our Shibuya office, my Tokyo apartment, coworking space or rented cottage in Hokkaido. It just happened that I picked Indonesia as my first destination  

Transition from on-site to remote work can be challenging, but It was not that difficult in the case of Lancers. Company outgrew the first office long time ago and splitted into two offices 5min walk apart away. To ensure communication in this distributed team is smooth, we use chat (chatwork) every day for ALL work related communication. Because my manager sat in different office, our communication did not change after my transition to remote. We use same chat as before. I have 1-on-1 meetings usually once a month with my manager and it seems to work fine. However what changes is my meeting attendance. I do not join any meetings. This gives me more time for actual programming, but makes me more disconnected from my team. Well this is one of the trade offs when working remotely 100% time. Some companies has only remote employees and no office. Having no place to meet forces them to create online company meetings. Other companies, which support partial remote work, can find quite challenging to connect remote employees with in-company meeting attendees. Another challenge which comes with remote position is social disconnect.

I am not Izakaya addicted, but sometimes I do miss that 乾杯 time with coworkers. I also did not see my friends from Lancers for a while. Humans are social creatures and we need to have connection with other people than chat app.

I usually work from home because it is time and cost-effective. I do not waste time by long commute as before. And I have more time to explore new places around and meet new people. Where is my home? Well, now, I am in the Holy city of Rishikesh in India, not far away from Himalaya. In the last 5 months, I lived in 3 countries, at 10 different places. I got my diving license in Indonesia (Gili Meno), I visited my cousin in Australia (Melbourne) and I joined my friend’s wedding here in India (New Delhi). I will join my lovely family for Christmas in Czech Republic. And during all that, I work on Quant service with time schedule same as any other employee.

I could write many pages how awesome it all is but I could also write many pages about struggles during my travel. I could say thousands of words praising my convenient Tokyo life and I could also talk about my “golden cage” feeling in Japan. My point is that I do not label my pre-remote life good or bad, nor I label my digital nomad journey. It is personal choice and I am blessed that technology enables me to pick a place where I want to work.

I do not have enough words to describe happy face of my parents when I told them I will visit them for a 3 weeks on Christmas. I believe digital nomad lifestyle is not for everybody, but working a few days in a month remotely can have great benefit for merely everyone.

It comes down to what you want, what you really deeply feel is good for you to grow as individual and member of the society.

World changed, remote work is already ubiquitous. I believe that more companies can move all their meetings to one or two days in a week and allow employees to work remotely for the rest of the week. Working from home will save wasted commuting time, reduce traffic jams, pollution and transportation cost. Bigger support of remote work will lead to revival of local areas, better work-life(family) balance and reduction of mental illness. Looks like we have bright future in the front of us.

Interesting facts:

  • In India, I bought data sim card with limit of 1Gb/day. It is valid for 70 days and costs 2000yen. So I can work even during taking taxi :D
  • I carry small wifi router. I used it several times as signal repeater when hotel wifi signal was too weak.
  • My camera gear is probably around 10Kg :D I do not own much more things than what I carry with me.
  • My girlfriend Tomoko did not travel a lot before. Now she travels with me, learn and teach yoga, and I think she likes it!
  • I like to use laptop stand and external keyboard for better ergonomy. Unfortunately, my keyboard broke during transport in Australia :(
  • I try to work during Japanese working hours. I started to work around 11 am in Australia and 5:30 am in India (Sometimes I overslept, but Tomoko also likes to wake up early so we support each other)
  • I do not like Japanese food overseas (Even when owners are Japanese), nothing tastes as good as real Japanese food in Japan.

 

本当です!私は世界を旅している間、ランサーズのソフトエンジニアとして、Quantプロジェクトの一員として働いています。私はソフトエンジニアもアドベンチャーも大好きです。そしてその大好きな2つのことを同時に行うことを決めました。

5か月前のある金曜日、最後に渋谷のオフィスを訪れました。それは会社を辞めることではなく、新たな出発でした。その翌日の土曜日、私は自分の荷物をまとめました。私のバリへのフライトは次の日の日曜だったからです。

パスポート?・・・持った!
チケット?・・・持った!
パソコン?・・・持った!
充電器?・・・持った!
マウス?・・・持った!
キーボード?・・・持った!
Wi-Fiルーター?・・・持った!
海パン?・・・持った!

翌日の月曜日、私はバリ島ウブドで朝を迎えました。そしてパソコンを開き、Wi-Fiに接続し、カンパニーチャットへログインしおはようございますと書き込みしました。ちょうど日本時間で9:00のことでした。

私の会社は私をリモートワーカーとして働くことを認めてくれました。私は仕事をするためにオフィスに行く必要はありません。リモートワークは私のようにデジタルノマドライフスタイルの経験をリモートのポジションは私に  どこで働きたいか選ぶことを認めてくれました。それは渋谷のオフィスの隣のスターバックスかもれないし、東京のアパート、コワーキングスペース、北海道のレンタルコテージかもしれません。私はインドネシアを最初の目的地として選びました。

通常会社に通勤するスタイルからリモートワークへのシフトは簡単ではなく、チャレンジですが、ランサーズならできると思います。会社は長い時間前に最初の事務所を越え、2つのオフィスに分かれて離れて5分歩いた。 この分散チームのコミュニケーションをスムーズにするために、私たちは毎日チャット(チャットワーク)を使用して、すべての仕事に関連するコミュニケーションを行っています。 私のマネージャーは別のオフィスに座っていたので、遠隔地に移行してもコミュニケーションは変わらなかった。 以前と同じチャットを使用します。私はいつも1ヶ月に1回、私のマネージャーと1対1のミーティングをして、問題があれば相談や報告をしています。 しかし、以前と変わった点は私の会議出席です。 私はどんな会議にも参加しません。私はその分プログラミングのためのより多くの時間がありますが、私は私のチームからより切り離されるように感じることもあります。 これはフルタイムリモートワークする場合のトレードオフの1つです。 リモート従業員のみで成り立っている会社も存在し、その場合オフィスはありません。会う場所がないので、オンライン会議をすることを強いられます。一部のリモート作業をサポートする他の企業では、リモートの従業員と社内の会議出席者を接続するのは非常に困難です。リモートワークのもう一つの課題は、社会的な切断です。私は居酒屋中毒ではありませんが、時々会社のみんなとの乾杯する時間が恋しくなります。

時間的な面からも費用対効果が高いので、私はたいてい家で働いています。以前のように通勤時間を無駄にしてしまうことはありません。新しい場所を探索し、たくさんの新しい人と会う時間もできました。今の私の家はどこでしょう?今はインドのヒマラヤの近くにある神聖な場所、リシケシにあります。この5か月の間で3つの国、10の都市に住みました。インドネシア(ギリメノ)ではダイビングライセンスを取得し、オーストラリア(メルボルン)では長年会えなかった従妹と再会し、楽しい時間を過ごし、またインド(ニューデリー)ではインド人の友人の結婚式にも参加しました。そして今年のクリスマスは母国のチェコで家族と過ごすつもりです。他の社員の方のように、同じタイムスケジュールで働いています。

私はこの経験がどれほど素晴らしいかお伝えすることができますが、それと同じように旅行中の苦労についても話すことができます。私はリモートワークについて、良い/悪い、またデジタルノマドの旅について評価したいのではありません。それは個人的な選択であって、テクノロジーが私が働きたい場所を選ぶことを可能にしたことに感謝しています。

クリスマスに3週間過ごせると話した時の両親の喜ぶ顔は言葉では表現できません。デジタルノマドライフスタイルは全ての人のためではありません。しかし、月に数日リモートで働くことは全ての人に大きな利益をもたらします。最も大切なことは、社会の中で個人として、また社会のメンバーとして成長することです。

世界は変化しています。リモートワークはすでにあらゆるところにあります。私はより多くの会社が全てのミーティングを週に1日か2日に変更し、残りの日は社員にリモートワークを認めるようになると信じています。自宅での勤務は無駄な通勤時間を節約し、交通渋滞、汚染、交通費の削減にもなります。リモートワークの大きな助けは、地方エリアの活性化にもつながり、よりよいワークライフ(家族)バランス、メンタル的な問題の減少にもなります。私たちの目の前に広がる可能性に目を向けてください。

面白いもの:

  • インドで1Gb/1日の制限付きのSIMカードを購入しました。使用期間は70日間、コストは2,000円です。タクシーの中でも私は仕事をすることができます。
  • 私は小さなWi-Fiルーターを携帯しています。ホテルのWi-Fiのシグナルが弱いとき、そのルーターを何度か使用しました。
  • 私は2つのバックパックとちいさなハンドバッグで旅をしています。それらトータルの重さは30kg以下です。
  • そのうち10kgがカメラ関係のものです。私は自分のものでカメラより重いものは持っていません。
  • 私の彼女のともこはこれまでそれほど旅をしていませんでした。しかし今彼女はヨガを学び、教えながら私と一緒に旅をしています。恐らく彼女もこのライフスタイルが好きだと思います。
  • 私はパソコンのスタンドとステージキーボードを使うのが好きです。オーストラリアへの移動中にキーボードは壊れてしまいましたが・・・。
  • また旅の間は、日本時間での勤務時間で働くようにしています。オーストラリアでは現地時間11時から、インドでは朝の5:30から働いていました。(時々寝過ごしてしまいますが、彼女も朝早く起きるのが好きなので、お互い助け合いながら時間を過ごしています。)
  • 私は海外で日本食を食べることが好きではありません。(たとえオーナーが日本人だったとしても)。日本で食べる日本食にかなうものはありません。

Storing 80 million records in Redis on cheap

Martin|2016年12月20日
DevOps

Hi, I am Martin and this article is about my journey optimizing Redis as key-value cache for millions of records. We have been using Redis from before, but never for such a big scale.

Redis is an awesome in-memory database. We use Redis as flexible cache for our Quant service. Redis has many data types to choose from but we will cover only String and Hash in this article as they are probably the most commonly used data types.

Redis Strings
The Redis String type is the simplest type of value you can associate with a Redis key. It is the only data type in Memcached, so it is also very natural for newcomers to use it in Redis.
Since Redis keys are strings, when we use the string type as a value too, we are mapping a string to another string. The string data type is useful for a number of use cases, like caching HTML fragments or pages.

From <https://redis.io/topics/data-types-intro>

I tried to use string as key-values store but got huge memory problems. We would have to scale up our EC2 instance resulting in increased bill and unanswered scalability questions. Common sense makes us think that using Redis’s String as plain key-value store is the way to go, but truth is that it is very memory hungry for storing hundred million records (however CPU efficient).

My optimization journey starts here:

I followed https://redis.io/topics/memory-optimization guide, but could not get satisfying results. I needed to improve memory consumption by 200%. Changing the Redis configuration file didn’t give me more than 10% performance boost. Changing data type from String to Hash surprisingly also didn’t help so much.

Redis Hashes
While hashes are handy to represent objects, actually the number of fields you can put inside a hash has no practical limits (other than available memory), so you can use hashes in many different ways inside your application.
It is worth noting that small hashes (i.e., a few elements with small values) are encoded in special way in memory that make them very memory efficient.

From <https://redis.io/topics/data-types-intro>

 

Use hashes when possible
Small hashes are encoded in a very small space, so you should try representing your data using hashes every time it is possible.
From <https://redis.io/topics/memory-optimization#use-hashes-when-possible>

I knew that Hash data type is the way to go but performance was very similar compared to String data type. Not 2-10x improvement as we have been promised. However I got encouraged by a blog post from Instagram’s engineers.

To take advantage of the hash type, we bucket all our Media IDs into buckets of 1000 (we just take the ID, divide by 1000 and discard the remainder). That determines which key we fall into; next, within the hash that lives at that key, the Media ID is the lookup key *within* the hash, and the user ID is the value. An example, given a Media ID of 1155315, which means it falls into bucket 1155 (1155315 / 1000 = 1155):

HSET “mediabucket:1155” “1155315” “939”
HGET “mediabucket:1155” “1155315”
> “939”

From <https://engineering.instagram.com/storing-hundreds-of-millions-of-simple-key-value-pairs-in-redis-1091ae80f74c#.7o2aw0dcp>

I used Hash with same key size (4 chars), but still didn’t get any promising results. However, there was one big difference. They use Integer keys, where we use UUID. I started to experiment with different key sizes for Hash and that was where I did hit our goal. I made a simple ruby script (Gist: https://gist.github.com/manfm/21106686dc8e281cf2a0470cb9fb4a1e) for generating millions of keys and ran that for different key sizes.

Results were promising:

redis_memory_rawRedis Hash memory allocation [GB] 

Lets take these raw data and calculate the memory consumption per 1 million records:

redis_memory_per_gbRedis Hash memory allocation [GB] per 1 million records

And put that data into chart:

redis_memory_per_gb_chart

We can clearly see huge memory consumption difference for variety of key sizes. (Missing data for 80M records is where my workstation ran out of memory.)

Conclusion:

I could cut memory consumption by 65% (0.108->0.038) using Hash with 5 char key size. Yet I could not find the right Redis configuration values to optimize memory consumption even more.
Redis Hash memory performance optimization is still a little bit of magic for me though I am very satisfied with the results. If you plan to use Redis with millions of records, definitely run tests to see which key size is best for you.

More to read:

https://engineering.instagram.com/storing-hundreds-of-millions-of-simple-key-value-pairs-in-redis-1091ae80f74c#.7o2aw0dcp
http://highscalability.com/blog/2014/9/8/how-twitter-uses-redis-to-scale-105tb-ram-39mm-qps-10000-ins.html
https://redis.io/topics/memory-optimization