HDE BLOG

コードもサーバも、雲の上

第25回 Monthly Technical Session (MTS) レポート

8/19に第25回 Monthly Technical Session (MTS)が行われました。 MTSは、主に技術的な興味関心、また現在行っていることから得られた知見を共有するための取り組みで、司会進行から質疑応答まで全編通して英語で行われる社内勉強会です。

f:id:doi-t:20160819211409j:plain

今回の司会はBagusさんでした。

f:id:doi-t:20160422173945j:plain

トップバッターの大久保さんには、HDEにおけるマルチテナント型MTAの実装の変遷を紹介していただきました。サーバリソースをテナント間で共有することで、低価格でMTAを提供することができるようになりましたが、これを実現するにあたって解決しなければならない課題と実装上の工夫を共有してくれました。

f:id:doi-t:20160819171904j:plain

2番手は小河さん、現在開発中のサービスから一部をピックアップしてそのシステム構成を紹介していただきました。クラウドネイティブな実装によって、容易にスケールアウトできるという大きな利点を得た一方で、コンポーネント間でDBスキーマを同期する大変さがある点とその課題を共有してくれました。

f:id:doi-t:20160819173409j:plain

3番手のJonasさんは、シングルサインオンのルールを記述するDSLの実装について話してくれました。ブラウザ上でこのDSLを使用するために、JavaScriptでDSLのコンパイラとランタイムを実装する中で得られた知見や、実装したDSLをデモを通じて紹介してもらいました。LT後のQ&Aでは、早速コンサルチームから機能要望のフィードバックが行われていました。

f:id:doi-t:20160819174929j:plain

4番手は田代さん、Elasticsearchを用いたログ解析について話してくれました。サービスの使用状況を解析して、kibana上で可視化する例や、Google Sheetsと連携してリスト化する例などを紹介していただきました。

f:id:doi-t:20160819182136j:plain

5番手のJeffreyさんは、開発中のサービスについて25分枠で詳細に紹介してくれました。4月に入社したJeffreyさんから、「他のチームが使っているツールや開発しているシステムのアーキテクチャをMTSで発表して欲しい」との要望があったため、ではまずは自分からということで自身が携わっているプロジェクトについて発表いただきました。発表では、プロジェクトで活用しているAWSのサービスやSaaSを紹介した後、システムの全体像から始まり、サービスの仕組み、デプロイメントフロー、ロギング、モニタリング、今後の展望などを説明してくれました。GithubやSlackを通じて、お互いのコードや会話は常時共有されている状態でありますが、時間を取ってシステムの詳細を全員に説明する機会はなかなかありません。そのような中、今回はMTSを通じてプロジェクトの全体像を共有する試みの第一弾となりました。

f:id:doi-t:20160819184508j:plain

6番手のBumiさんには、メールをOutlook Personal Folders (PST) 形式でエクスポートするライブラリの開発について紹介していただきました。エクスポートしたメールをOutlook上で開くには、メールのフォーマットを.pst形式に変換する必要があり、これを行うライブラリを実装するにあたって知る必要がある複雑なPSTのデータ構造について解説してくれました。

f:id:doi-t:20160819191021j:plain

終わった後は、After-Party!

f:id:doi-t:20160819194541j:plain

第24回 Monthly Technical Session (MTS) レポート

7/22に第24回 Monthly Technical Session (MTS)が行われました。 MTSは、主に技術的な興味関心、また現在行っていることから得られた知見を共有するための取り組みで、司会進行から質疑応答まで全編通して英語で行われる社内勉強会です。

今回の司会はjonasさんでした。また、当日はijinさんが飛び入り参加で各LTのQ&Aにも参加いただきました。

f:id:doi-t:20160728101221p:plain

トップバッターの楠本さんは、学生時代に南極で行った研究について紹介してくれました。 現地では南極の大気の情報集めるバルーンと連携して、情報をストレージに溜め込む装置のソフトウェアをメンテナンスしていたそうです。 Q&Aでは、バルーンの回収はどうするのかとの問いに対して、気流に乗って漂うだけで、最後はどこかに落ちる仕様との回答に、一同驚きの様子でした。

f:id:doi-t:20160728101225p:plain

2番手の林さんは、開発バージョンで発生したメモリリークの原因を突き止めるために使用したpythonのツール群 (memory_profiler, Pympler, gc) をデモを交えつつ紹介してくれました。環境の制約によっては各ツールが有効でない場合もあるので、状況や目的に応じて使い分ける必要があります。

f:id:doi-t:20160728101229p:plain

前半のセッションの最後は田邊さん。サーバレスアーキテクチャで実現した監視システムについて。CloudWatch Eventsを契機にAPI Gateway, lambda, SES, SNS, CloudWatch Metricsなどが連携して、閾値を超えた監視項目がslackへ通知される実例を示してくれました。 これによって"誰が監視システムを監視するのか問題"を解消しつつ*1、lambdaによる自由なシステム監視とそのメトリクス可視化という大きなメリットが得られました。

f:id:doi-t:20160728101232p:plain

休憩を挟んで4番手は牧さん。"kubernetes in 20 minutes"というタイトルで、k8sの知見を共有してくれました。k8sとは何か、またk8sに触れるに当たって理解しておく必要があるCluster, Node, Pod, Replica Set, Deployment, Services, Secrets, ConfigMaps, Ingress, DaemonSets, PetSetsなどの概念がどのような役割でお互いどのような関係を持つのかをわかりやすく解説してくれました。アップデートの激しさも相まって、便利だけれども一筋縄ではいかない難しさがあるようです。

f:id:doi-t:20160728101234p:plain

5番手は先月からGIPインターン中のTze-Chenさん。現在大学の研究で使っているHadoopについて。Googleが発表した2つの論文 ( The Google File System , MapReduce: Simplified Data Processing on Large Clusters) によって明らかになったHadoopがどのような目的で作られたのか、facebookが管理する世界最大規模のHadoopクラスタや、MapReduceの仕組みなど、Hadoopの概要を説明してくれました。

f:id:doi-t:20160728101237p:plain

ラストは同じくGIPインターン中のRizkiさんが様々な暗号化手法について。暗号化手法別の分類と歴史的な分類の二つのアプローチで各手法がどのような経緯と特徴を持つのかを解説してくれました。また、実例としてエニグマ暗号機を紹介してくれました。

f:id:doi-t:20160728101240p:plain

発表の後はAfter-Party!! MTSはエンジニア同士の知見共有の場として開かれていますが、このAfter-PartyもまたGIPインターンも含めた社内の誰でも参加可能な交流の場として開かれています。

f:id:doi-t:20160728101243p:plain

ちなみに、この日はPokemon Goのリリース日だったので、会場は完全にPokemon Go試遊会と化していました。

f:id:doi-t:20160728101731j:plain

f:id:doi-t:20160728101736j:plain

*1:それでもなお"誰がAWSを監視するのか問題"があるにせよ!

第23回 Monthly Technical Session (MTS) レポート

6/24に第23回 Monthly Technical Session (MTS)が行われました。

MTSは、主に技術的な興味関心、また現在行っていることから得られた知見を共有するための取り組みで、司会進行から質疑応答も含めて全編通して英語で行われる社内勉強会です。今回も前回に引き続き多彩なトピックを社内で共有することができました。

今回の司会は篠原さんでした。

f:id:doi-t:20160624165517j:plain

まずは中津さんがウェアラブルについて話してくれました。今回は運動中のHEART RATEを監視することで、ペース配分に役立てる例を示してくれました。次は違った角度からのウェアラブル紹介ということでシリーズ化の予定です!

f:id:doi-t:20160624171241j:plain

2人目の柳楽さんはAWS Summit Tokyo 2016のレポートをしてくれました。たくさんあった講演の中からBig Data Pipeline (pdf)とCode Pipeline (pdf)を取り上げて、その内容を共有していただきました。 f:id:doi-t:20160624172627j:plain

3人目はShi Hanさん。"Go i18n"というタイトルで、GoにおけるInternationalizationについて発表してくれました。現時点では選択肢が少なく (i18n4go, go-i18n)、まだまだ発展途上 (Ref. Proposal: Localization support in Go) ということもあり、その苦悩を共有してくれました。当日はQ&AでPythonやJavaScriptとの比較等で白熱した議論となり、後日gettextのGo実装を行うに至りました! f:id:doi-t:20160624174532j:plain

休憩を挟んで4人目のIskandarさんは、Android開発のイントロダクションをしてくれました。世界での普及率、バージョンの歴史と問題、アーキテクチャなどの解説の他に、実装方法の選択肢や具体的な実装例を示してもらいました。 f:id:doi-t:20160624180509j:plain

5人目は最近アルバイトとしてjoinしてくれているNuttさん。タイ語におけるN-gramによる全文検索について、その概要とUnicodeに由来する難しさを紹介してくれました。タイ語は1文字が複数の文字の組み合わせで構成されることから、検索の際にはタイ語に合わせた工夫が必要になるようです。 f:id:doi-t:20160624183146j:plain

最後は、インターンのGavinさん。型システムについて、そもそも型とは何かから始まり、Lambda cubeの解説や、実際問題としてRustやJavaScriptにおける実装がどうなっているのかをデモを通じて説明してくれました。

f:id:doi-t:20160624184958j:plain

この日は、RendongさんとGavinさんのインターン最終日だったので、恒例の修了式を執り行いました。6週間に渡るインターンお疲れ様でした!

f:id:doi-t:20160624190934j:plain

One Month in Beijing - Remote work as a developer

This is Xudong from development team. It's been a while since my last post. I would like to share my experience of working remotely in Beijing this time.

Due to some private matter, I had to live in Beijing for several weeks to stay with my family. However, during this time, it seems to be unnecessary to take a vacation as I have enough spare time to do the work. Also, we had just welcomed a new developer, Bumi san, into our team. It would be great if I could help him to get accustomed to our development team quickly. So this time, I tried to work remotely. And this has got full support from my team mates and manager of development team, Minoura san. I really appreciated it.

What remote working is like

My remote work started from the last week of April, a week before Golden Week in Japan and it lasted over a month. There is only one hour time difference between Beijing and Tokyo. So I managed to work at almost the same time with my colleagues.

Every day, I went online at my usual time to office in the morning from home and worked until the time I usually leave office. During this time, everything was the same as I'm in office as I mainly do development work which includes designing features, writing and reviewing code and writing documents with my own PC for work. Of course, I need to update myself with what is happening in office and communicate with my team mates. And I found it easy to do those things as we already adopted a lot of tools to work and collaborate online.

Tools and methodology

There are a lot of experience sharing post about what specific tools should be used for remote working. However, I found them not quite helpful as a lot of them are quite complicated to use across the team. I realized that we (my team mates and me) just needed tools to let us easily get updates with the progress of each other and tools to make communication smooth and efficient. And we were able to achieve that with what we already have:

  • github - for development
  • slack - for text communication
  • skype - for vocal and video communication
  • yammer - for announcement
  • google for work - for document sharing
  • HDE One, of course - for access control

and other online services that we use for development.

We held a small meeting within our team on skype every day for around 10 minutes before I went offline. Aside from that, there was nothing specific done for my remote working. And everything went smoothly.

Others

Remote work saved my time significantly. I didn't need to commute to and from office, which usually takes around 3 hours. Since I work at home, I managed to start working right after my breakfast. I even got time to prepare my own lunch during the lunch break as I usually have lunch by myself.

However, I gained some weight during this one month because of apparently lacking of exercise and staying indoors too much. I should have spent more time going outdoors and doing exercise after work.


My team and I managed to work without much difficulty during this one month. I'm quite happy that I had a chance to try remote working out. I would like to try more if it is possible.

Finally, a photo I took from Beijing Botanical Garden during this one month.

f:id:yxd-hde:20160608175240j:plain

第22回 Monthly Technical Session (MTS) レポート

5/27に第22回 Monthly Technical Sessionが行われました。

前回に引き続き、今回も7名のメンバーが各々持ち寄ったトピックについて発表してくれました。

今回の司会はBagusさんでした。

f:id:doi-t:20160527165948j:plain

まずは木暮さんがDataScopeというタイトルで、今後社内に広く展開する予定のデータ分析基盤を紹介してくれました。あらゆるログを収集して分析することで、PDCAサイクルのCheckフェーズに対して、詳細なKPIを提供することができるようになるこの分析基盤を、将来的には横断的にチームやシステムに提供していく計画を示してくれました。

f:id:doi-t:20160527170210j:plain

次に、荒川さんが、メールのTLS暗号化について、その仕組みと世の中の浸透具合を共有をしてくれました。2016年2月9日にGoogleがgmail上でメールの暗号化の明示するようになったのは、記憶に新しい方も多いと思いますが、世の中的にはまだまだ浸透しきったとは言えない状況のようです。

support.google.com

f:id:doi-t:20160527171654j:plain

3番手は、直前にde:codeに行っていた小玉さんからイベントのレポートでした。より一層OSSへ寄り添う姿勢を見せるMicrosoftの変化を共有してもらいました。発表の最後には"Even Microsoft was able to change. We should be able to do the same."と言う提言が投げかけられました。

f:id:doi-t:20160527173006j:plain

休憩を挟んで...

f:id:doi-t:20160527174718j:plain

4番手はBumiさんによるAPI Gatewayの紹介でした。RESTfull APIの話から始まり、実際にAPI Gatewayでエンドポイントを作る流れや、Swaggerswagger importerの紹介などがありました。

f:id:doi-t:20160527175532j:plain

5番手のKevinさんは、JavaScriptのビルドツールについて。たくさんある中でもGruntGulpの紹介をしていただきました。フロントエンドのチームではこの発表を機に早速ビルドツールの見直しが始まっているようです!

f:id:doi-t:20160527181456j:plain

6番手は先月から新たに開発部門にてインターンを開始したRendongさん。IPython及びJupyterをデモを交えながら紹介してくれました。また、様々な言語に対応したJupyter NotebookがGithubやnbviewer上で公開されており、自由に使えます。

f:id:doi-t:20160527183049j:plain

今回、当日中国でリモートワークしていたXudongさんがリモートで参加してみる、という試みが行われました。これは中国から質問している様子。

f:id:doi-t:20160527183325j:plain

最後は、今日でインターン最終日だったAnastasiiaさん。インターン中に得た成果の一部として、ウクライナのIT事情について。実はIT人材が非常に多いウクライナの現状をデータと共に共有してくれました。

f:id:doi-t:20160527183651j:plain

MTS終了後、2カ月に渡るグローバルインターンを終えたAnastasiiaさんの修了式を取り行いました。

f:id:doi-t:20160527185443j:plain

MTSの後はAfter-party!

f:id:doi-t:20160527190858j:plain

f:id:doi-t:20160527190931j:plain

LXC : A Quick Overview

Hello, my name is Jeffrey Lonan, currently working as a DevOps Engineer in HDE, Inc.

This post is based on my presentation during HDE's 21st Monthly Technical Session.

Containers, Containers Everywhere!

As DevOps practitioners these days, containers are a part and parcel of our working life. Developers use them to test their Applications in their efforts to quash every last (major) bugs in their app. Operators use them to test their infrastructure configurations in their quest to create the ultimate “Infrastructure-As-A-Code” setup, or even deploying and running containers as part of their infrastructure.

One of the most well-known container solution out there is Docker, as well as the up and coming rkt. These are Application Containers, whereby the design philosophy is to reduce a container as much as possible to only run a single process, ideally the application we want to run, and package it into a portable container image, which then can be deployed anywhere. Some application container providers (e.g. Docker) have an extensive toolset to make it easier to build & customise container images and deploying them into the infrastructure.

There are advantages and disadvantages concerning the Application Container philosophy, but we will not dwell on it in this post. Instead, let's get into a different way of running containers!

System Containers

Enter LXC . LXC is a System Container, which means that it is a Container that is designed to replicate closely a Bare Metal / VM host, and therefore you can treat LXC containers as you would treat a normal server / VM host. You can run your existing configuration management in these containers with no modifications and it will work just fine. f:id:jeffrey-lonan:20160523101106p:plain

LXC started as a project to utilize the cgroups functionality that was introduced in 2006, that allows separation and isolation of processes within their own namespace in a single Linux Kernel. Some of the features in LXC includes

  • Unprivileged Containers allowing full isolation from the Host system. This works by mapping UID and GID of processes in the container to unprivileged UID and GID in the Host system
  • Container resource management via cgroups through API or container definition file. The definition file can easily be managed by a configuration management tool
  • Container rootfs creation and customization via templates. When creating a container with a pre-existing template, LXC will create the rootfs and download the minimal packages from the upstream repository required to run the container
  • Hooks in the container config to call scripts / executables during a container’s lifetime
  • API and bindings for C & Python to programmatically create and manage containers
  • CRIU support from LXC 1.1.0 onwards (lxc-checkpoint) to create snapshots of running containers, which then can be copied to and re instantiated in another host machine

Our First Container

On a Linux system, you can use your favourite package manager to install lxc. For this example, let's use yum with CentOS 7

$ yum install -y lxc bridge-utils

the bridge-utils package is needed as the containers will communicate with the outside world via the host system's network bridge interface.

Assuming you have created a bridge interface called virbr0, let's proceed with actually launching a container! We will use lxc-create command will create the root file system (rootfs) for our container, using CentOS and named test01

$ lxc-create --name test01 -t centos
Host CPE ID from /etc/os-release: cpe:/o:centos:centos:7
dnsdomainname: Name or service not known
Checking cache download in /var/cache/lxc/centos/x86_64/7/rootfs ... 
Cache found. Updating...
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.iij.ad.jp
 * extras: download.nus.edu.sg
 * updates: ftp.iij.ad.jp
No packages marked for update
Loaded plugins: fastestmirror
Cleaning repos: base extras updates
0 package files removed
Update finished
Copy /var/cache/lxc/centos/x86_64/7/rootfs to /var/lib/lxc/test01/rootfs ... 
Copying rootfs to /var/lib/lxc/test01/rootfs ...
Storing root password in '/var/lib/lxc/test01/tmp_root_pass'
Expiring password for user root.
passwd: Success

Container rootfs and config have been created.
Edit the config file to check/enable networking setup.

The temporary root password is stored in:

        '/var/lib/lxc/test01/tmp_root_pass'


The root password is set up as expired and will require it to be changed
at first login, which you should do as soon as possible.  If you lose the
root password or wish to change it without starting the container, you
can change it from the host by running the following command (which will
also reset the expired flag):

        chroot /var/lib/lxc/test01/rootfs passwd

So our container rootfs has been created! Note that LXC will auto generate the SSH password for first-time login. Let's start our container using lxc-start and check for running containers with lxc-ls --active

$ lxc-start -n test01 -d
$ lxc-ls --active
test01

Our first container is up and running! We can access the container using SSH with the auto-generated password. If we are not sure about the IP address, we can also use the lxc-attach command to gain access to your container and do whatever is needed with your container (e.g. Installing packages, set IP address etc.).

$ lxc-attach -n test01
[root@test01 ~]# cat /etc/hosts
127.0.0.1 localhost test01

Our first container was created and instantiated using default settings, but default setting is no fun! At some point in time, we would like to customise our containers, so for this, we would need to create the container configuration files.

LXC Container Configuration

By default, the container config file will be created in the path you specify when running lxc-create, of which the default value is /var/lib/lxc/<container-name>/config. Here is a sample of a container custom configuration file of container named lxc3

# LXC Container Common Configuration
lxc.rootfs = /mnt/lxc3/rootfs
lxc.include = /usr/share/lxc/config/centos.common.conf
lxc.arch = x86_64
lxc.utsname = lxc3
lxc.autodev = 1
lxc.kmsg =1

# LXC Container Network Configuration
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = virbr0
lxc.network.name = eth0
lxc.network.ipv4 = 192.168.99.21/24

# LXC cgroups config
lxc.cgroup.cpuset.cpus = 0-1
lxc.cgroup.memory.limit_in_bytes = 1073741824

# LXC Mount Configs
lxc.mount.entry = /opt/lxc3 opt none bind 0 0

# LXC Hooks
lxc.hook.pre-start = /mnt/lxc3/setenv.sh

The configuration file above is used to define the container properties, like hostname, IP addresses, host folders to be mounted, among other things, using key-value pairs. We won't go into details on the container configurations here, so if you are curious about the configuration file, do check out the documentation.

LXC Python APIs

So, you've configured your container configurations and created your containers. So what next? Automate your container deployment and configurations? Of course!. I created a simple Python script for the previous MTS session to create and start a container, so let's check it out!

#!/usr/bin/env python
import lxc
import sys
import argparse

parser = argparse.ArgumentParser(description='Create a LXC container')
parser.add_argument('--name', help='Container name')
parser.add_argument('--create', help='Create the Container', action="store_true")
parser.add_argument('--start', help='Start the Container', action="store_true")
parser.add_argument('--stop', help='Stop the Container', action="store_true")
args = parser.parse_args()

#Set Container Name
c = lxc.Container(args.name)

#Set container initial configuration
config = {"dist":"centos","release":"7","arch":"amd64"}

#Create Container
if args.create:
 print "Creating Container" 
 if c.defined:
        print ("Container exists")
        sys.exit(1)

 #Create the container rootfs
 if not c.create("download", lxc.LXC_CREATE_QUIET, config):
        print ("Failed to create container rootfs",sys.stderr)
        sys.exit(1)

#Start Container
if args.start:
 print "Starting Container"
 if not c.start():
        print("Failed to start container", sys.stderr)
        sys.exit(1)
 print "Container Started"

# Query some information
print("Container state: %s" % c.state)
print("Container PID: %s" % c.init_pid)

#Stop Container
if args.stop:
 print "Stopping the Container"
 if not c.shutdown(3):
    c.stop()

 if c.running:
    print("Stopping the container")
    c.stop()
    c.wait("STOPPED", 3)

You will need to install the lxc-python2 package using pip and import it to your script. So, to create a container and start it up, I simply run the following

$ ./launch-lxc-demo.py --help
usage: launch-lxc-demo.py [-h] [--name NAME] [--create] [--start] [--stop]

Create a LXC container

optional arguments:
  -h, --help   show this help message and exit
  --name NAME  Container name
  --create     Create the Container
  --start      Start the Container
  --stop       Stop the Container

$ ./launch-lxc-demo.py --name test01 --create
Creating Container
$ lxc-ls
test01
$ ./launch-lxc-demo.py --name test01 --start
Starting Container
Container Started
Container state: RUNNING
Container PID: 689
$ lxc-ls --active
test01
$ lxc-attach -n test01
[root@test01 ~]# 

You can also get and set the container configuration via the API to update your container configuration programmatically. For more information on the APIs, please check out the documentation here

Conclusion

So we have gone through some of the more interesting features available in LXC. There are more features in LXC that cannot be covered by this post, so if you are interested for more information, please visit the official LXC website at Linux Containers. You can also check out the excellent blog posts by Stéphane Graber, the project lead on LXC, here.

As an Operator, I have used both Docker and LXC for testing and deploying infrastructure, and personally, I prefer LXC due to its VM-like characteristics, which makes it easy for me to run my existing configuration management manifests inside LXC.

I also enjoyed the flexibility afforded by the LXC configuration file, and in fact, I have used my configuration management tool to create & maintain LXC configuration files and launch customised container into the infrastructure. With new tools like LXD coming up, I am confident that LXC will find its place in DevOps, alongside Docker and rkt.

Configuring an AWS Lambda Function to Access Both Resources in Public Internet and an Amazon VPC

Hello, this is Bagus from HDE, Inc.

This post is a summary of my presentation on HDE's 21st Monthly Technical Session.

Recently, I’ve been working more with AWS Lambda. There was a time when I created a Lambda function which accesses both resources in public internet and an Amazon VPC. I learned quite a lot from it, so I'd like to share the experience.

続きを読む