re:annkara

日々学んだことを書き留めておく。

2017年の振り返りと2018年の目標

雑記

2017年の振り返り

とある業務アプリケーションのパフォーマンステストと、タスク管理ツールであるJIRAの運用ばかりやっていた気がする。

パフォーマンステスト

普段扱っているシステム規模はユーザ数で見ると多くとも5,000ユーザくらいの規模だったのだけど、その10倍のユーザ数が見込まれるシステムを構築するということで、パフォーマンステストの期間を十分にとって検証するということを半年くらいやっていた。

主にスループット（単位時間あたりのトランザクション処理件数）やキャパシティ（高負荷時のCPU使用率、メモリ使用率、ディスク容量）などを検証のポイントとして、スクリプトを作成し、実行、検証などを行っていた。

パフォーマンステストにおいて大事なことは、システム全体の構成を把握し、適切な箇所を適切な方法でモニタリングするということが非常に重要だと学んだ。 実際、サービスイン後モニタリングしていた部分においては障害は発生しなかったものの、モニタリングしていなかった部分が原因で障害が発生してしまった。モニタリングや監視をしていない部分については、障害が発生しても運用側からは検知することができないことを経験し、改めてモニタリング・監視の重要性を学んだ。

また、パフォーマンステストについて組織内に体系だった知見がまとめられていないため、自分が主担当として実施する際に効率よくテストを行えなかった気もする。その辺の体系化をしようしようと思いつつも年があけてしまったので、今年の目標の１つとしてまとめていきたいなと思う。

JIRA

JIRAの管理者をやっているので、設定周りにはだいぶ強くなった気がする。
ただ、実際の現場に導入しようとすると、今までのやり方（Excelによる管理）からだいぶ変わってしまうことだったり、ExcelでできたことがJIRAではできなくなってしまうことから現場からの反発はだいぶ受けてしまった。
JIRAだけに限らずこういったツールを導入する際にはまず、ツールを利用する以前のあるべき姿を定義し、それを実際の利用者と共有するということが非常に重要なことだと実感した。
極々当たり前のことだけど、実際の利用者からのヒアリングと課題の共有、そしてそれに見合った解決策を考えていくというのが非常に重要なのだと実感した。

プログラミング

メインフレームとの通信を行うインターフェースライブラリの実装や、JIRAのREST APIを叩くクライアントライブラリの開発などをしていたものの、プライベートではほとんどプログラミングしていなかった。
テスト駆動開発のxUnitをJavaで再実装したりはしたものの、実際に何か学んだかと言われると何も身についていないので、ほとんど意味がなかったと思う。

2017年まとめ

インフラエンジニアではないものの、システムの運用に携わることが多かった一年だった。
振り返ってみると自分はアプリケーション開発（エンドユーザーに利用してもらう実サービスの実装という意味で）でもインフラ（物理的なサーバ、ネットワークを取り扱う領域という意味で）でもなくその中間層を扱うことが好きなのかもしれないと感じている。
この中間層というのがSREやウェブオペレーションエンジニアリングといった分野だとは感じているものの、自分のなかでまだ整理ができていない。
ただ、自分が進みたいと思う大きな方向性というのは得られたと思うので、今までに比べると実りある1年だったと思う。

2018年の目標

今年で30を迎えるので、今一度自分の人生というものを考えていきたい。

人生について

今まで自分の人生というものを真面目に考えてこなかったと思う。
受験や就職活動といった人生のイベント事においては、その都度目の前の目標をクリアすることばかり考えていたけど、どういった人生を送りたいのかということを真面目に考えたことはなかったと思う。
自分がいつ死ぬかなんてわからないけど、少なくとも直近3年間をどのように生きていきたいかくらいは真面目に考えたい。

エンジニアとして

Webシステムの信頼性を向上させるためのエンジニアリングを身につけていきたい。
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチームやウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)といった書籍を中心に、Linux、Web・DB、HTTP、TCP/IP、CD/CI、監視、モニタリング、MSA、プログラミングといったキーワードを今一度学び直していきたい。
また、学んだことや考えたことを適切に言葉として表現する力も身につけていきたい。何かを思考するということは好きなのだけど、人に伝えるという行為が非常に苦手なので。
プログラミングに関しては、それ自体を目標とするのではなく、何かを実現・解決するための実装をすることを目標としたい。個人プロダクトを実装することができれば良い。

健康面

社会人になってからというものの、体重が右肩上がりなので痩せたい。現状、67kgなのでせめて63kgくらいまでは落としたい。
単純に飲み過ぎだと思うので、節制したい。

金銭面

貯蓄はしてるものの、収入が会社からの給料だけなのも不安なので、複数の収入源を得たいと思う。
今流行っている仮想通貨でもいいし、株でもなんでも良いので。

2018年まとめ

30という節目を迎えるにあたり、ちゃんと自分の人生というものを生きていきたい。
それはなんとなく生きていくのではなくて、自分でしっかりと考えて行動するということだと考えている。
そのためにも日々振り返ってみて、都度ブログにまとめていきたいと思う。

Dockerメモ

docker 読書 メモ

職場でもいよいよDockerの導入が検討され始めたので、本腰入れて学習していくかと思い積読となっていたオライリーのDockerを読みました。

Dockerコマンド周りやDocekrfileの記述方法など、細かいところをまとめていくのはしんどいのでDocker周りの技術を中心にまとめていこうと思います。
Dockerをローカル開発環境だけでなく、オンプレ上の開発環境、本番環境に適用して行く際に、導入・運用に必要となるであろう技術スタックを俯瞰できるようにしておきたいというのがメモの目的なので。

あくまで書籍ベースなので、情報が古い場合もあるのでご注意を。

Dockerのアーキテクチャ

Dockerデーモン

コンテナの生成、実行、モニタリングとともに、イメージの構築と保存を担う。 常駐プロセスとしてサーバなどで稼働しており、Dockerクライアントからのリクエストを受け付ける。

Dockerクライアント

HTTP経由でDockerデーモンに通信するために利用される。
dockerコマンドがクライアントに相当するものだと思うのだけど、HTTPが話せればよいということなので、クライアントライブラリ経由でも可能らしい。
今の所あまり理解できていない気がする。

Dockerレジストリ

イメージの保存と配布を担う。
デフォルトのレジストリはDocker Hubで、ローカルに存在しなければDocker Hubに探しに行く。
もちろん独自のDockerレジストリを立てることも可能。

Dockerの周辺技術

Docker単体のみでサービスを構成することは難しいため、それを補う技術がある。
Dockerが提供するものもあれば、サードパーティ製のものもあり、ユーザはそれを取捨選択することができる。

Dockerが提供するものは以下の通り。

Swarm

Dockerのクラスタリングツール。
Dockerホストが複数立ち上がっている場合、統合して扱うことができる。

Compose

Swarmが分散されたDockerホストを統合するツールであれば、Composeは同一ホスト上で稼働する関連したDockerコンテナ群を統合するためのツール。
docker-compose.ymlファイルに各コンテナの設定を記述することで、複数コンテナの起動や停止を管理できる。

Machine

Dockerホストをローカル、またはリモート上に構築するためのツール。

Kitematic

Mac OS及びWindows向けのDockerコンテナを管理するためのGUIツール。

Docker Trusted Resistry

オンプレミス上でレジストリを構築するためのサービス。
他にもパッケージ経由でインストールできる、Docker Resistryもある。

他にもサードパーティ製のサービスは以下のように大きく分類できる。
ここでは列挙にとどめておく。詳しいことは各分野毎のツールを実際に試してみて、また別の記事としてまとめておきたい。

ネットワーキング
  • Weave
  • Project Calico
サービスディスカバリ
  • etcd
  • SkyDNS
  • Consul
クラスタリング及びオーケストレーション
  • Kubernates
  • Mesos
  • Fleet
コンテナ管理
  • Rancher
  • Clocker
  • Tutum

感想

Docker自体が発展途上の技術であり、それを取り巻く環境も変化が激しい分野だと思います。
他の技術同様、利用することを目的にしてしまうと変化に追いつくだけで疲れてしまうと思うので、Dockerはどんな技術で何を解決するものなのか、
そして自社の環境にどのような形で適用していくことができるのかということを念頭に置かないといけないなと思いました。
そういった意味では今回、そもそもDockerとは、コンテナ技術とは、など基本的なところをまとめていないのでまとめていきたいと思います。

ただコンテナ技術としてのDockerを考えると、アプリケーションとその依存関係をイメージとして固め、docker runすれば簡単にアプリケーションが起動できるという仕組みは非常に便利だとも思います。
要は使い方さえ間違わなければ便利なツールであると。
どうやって利用していくのかという点も引き続き考えていきたいと思います。

docker + fluentdでハマった話

docker fluentd

データ分析基盤構築入門を購入していたので、読み進めようと思ったら環境構築でハマったのでメモしておく。

書籍上では、dockerがインストールされていれば、GitHub - efkbook/blog-sample: a kind of blog implementation written in Go integrated with fluentd and Elasticsearchここからクローンして、docker-compose up で各コンテナ群が立ち上がるとのことだったが、fluentdのコンテナが何故か立ち上がらなかった。

とりあえず対症療法的に、以下のようにDockerfile-fluentを書き換え、コンテナとイメージを削除したら起動するようになった。

FROM fluent/fluentd:v0.12-debian  
RUN ["gem", "install", "fluent-plugin-elasticsearch", "--no-rdoc", "--no-ri", "--version", "1.9.2"]  
RUN ["gem", "install", "fluent-plugin-record-reformer", "--no-rdoc", "--no-ri", "--version", "0.9.1"]

とりあえずのメモということで。

ジェネリクス入門

Java Generics

Javaのジェネリクスについて、自分なりにまとめておきたいと思う。
謝り等ありましたらご指摘いただけると幸いです。

ジェネリクスが使えると何が良いか？？

いきなりだけど、ジェネリクスのメリットを考えて見る。
例えば、オブジェクトを保持する適当なクラスは以下のとおり。

public class Box {

    private Object obj;

    public void add(Object arg){
        this.obj = arg;
    }

    public Object get(){
        return this.obj;
    }
}

このBoxクラスをインスタンス化する場合、Objectクラスなのであらゆるオブジェクトを扱うことができる。
あらゆるオブジェクトを使える一方で、StringやInteger、もしくはユーザ定義したクラスのオブジェクトなどを扱う際には、 getメソッドを呼び出す際に、必ずキャストしなければならない。

Box box = new Box();  
box.add("文字列を格納");  
String str = (String) box.get();

このキャストを忘れてしまうと、実行時にClassCastExceptionが発生してしまう。
ここで問題となるのは以下の2点になる。
1. プログラマにキャストを強制する。　→　キャスト忘れちゃうかも。
2. 実行時されるまでこのクラスを利用した処理が成功するかわからない。　→　コンパイル時にわかった方がよくない？？

だからといって、文字列を扱うStringBoxクラス、Integerを扱うIntegerBoxクラス、ユーザ型を扱うUserBoxクラス、、、、などなどと、 各オブジェクトに対応するクラスを作成するのはなかなかに辛さがある。
ここで、任意の型を扱うBoxクラスというのを定義できたらいいんじゃない？？というわけででてきたのが、ジェネリクスである。
上のBoxクラスをジェネリクス型に置き換えると以下のとおり。

public class Box<E> {

    private E obj;

    public void add(E arg){
        this.obj = arg;
    }

    public E get(){
        return this.obj;
    }
}

クラス宣言に<E>を付け加えて、Objectと宣言していたところを単にEで置き換えただけだけど、こうするだけでキャスト不要で、 コンパイル時に型チェックが入る任意のBoxクラスを作ることができた。
ジェネリクスがあれば、キャスト処理も特有のクラス定義も不要で、安全で柔軟な型を定義することができる,というのが個人的にはメリットだと考えている。

ジェネリクス周りの用語の整理

<E>の表記が登場したので、ここでジェネリクス周りの用語を整理しようと思う。
用語の一覧はEffective Javaの項目23から抜粋。

  1. ジェネリクス型
    Box<T>

  2. 仮型パラメータ、仮型変数
    T
    通常大文字1文字で表現されることが多い。名前自体はなんでも良いが、TはType、KはKeyを表すなどの慣習は存在する。

  3. パラメータ化された型、ジェネリクス型の呼び出し
    Box<String>
    型パラメータに具体的な型 (Stringなど)を代入することで、その型の役割( どの型を扱うことができるか)を決める程度に理解している。

  4. 実型パラメータ、実型変数
    String など
    仮型パラメータに代入される具体的な型。

  5. raw型
    Box
    ジェネリクス型を使用しない型のこと。特段の事情がない限り、raw型を使うべきではない。

ワイルドカードや境界型パラメータなど、まだ出てきていない概念については後述しようと思います。
思いの外長くなってしまったので、一旦ここまでで。

はじめてのJJUG CCC #jjug_ccc

生まれて初めてのカンファレンスということで、

JJUG CCC 2016 Fall

に参加してきました。 当日の登壇者の方々の資料は以下にあるそうです。

GitHub - jjug-ccc/slides-articles-2016fall: JJUG CCC 2016 Fallの発表資料およびブログ記事まとめ

参加したセッション

当日は想像以上に参加者の方が多く、会場の雰囲気にのまれてあまりメモったりできなかったのですが、 今振り返ってみると、今後の学びのヒントがいろいろと得られたと思うので、そのことについて書いていきたいと思います。 メモ書きなのでだいぶ粗いです 汗

SIerもはじめる、わたしたちのDevOps

@syobochimさんと@_Dr_ASAさんのセッション。 @syobochimさんのセッションではDevOpsの説明から、業務への適用までのお話をされていました。 仮説→検証→実践→振り返りのサイクルを回しながら開発していくのは、成果が短時間で目に見えて楽しいだろうなぁと思ったり、その一方で、お客さんがDevOpsという考え方をちゃんと理解していたり、適用する範囲も全て適用できるわけではなさそうかなとも思いました。*1 技術的な面では、enkanやfalchion-containerを利用して、デプロイ時間の短縮や無停止デプロイの実現など、だいぶ興味深いことをされていたので、ここらへんのお話は自分でも深めていきたいと思いました。

かわって@_Dr_ASAさんさんのセッションではDockerの話題を中心に、変化に強いシステムであったり、システム構築するにあたり組織としてのあり方やエンジニア個人としてのこれからのあり方をお話されていました。特にエンジニア個人としてのあり方には非常に共感するところがあり、様々な分野の知識を自分で習得していく必要があるという部分は日々思っていることなんですけど、あまり実践できずということもあり、頑張っていきたいなぁと（小学生並みの感想）。

Javaの型システム再入門 〜オブジェクト指向からジェネリクスまで〜

@nagiseさんのセッション。 仕事ではなんとなく使っていて、チュートリアルを見てもイマイチ理解できなかったので参加させていただきました。 硬派な内容だったので、途中から理解がついていけなくなってしまったあたり、まだまだなのだなと実感しました。 ジェネリクス周りはまた別途自分で調べてみて内容をまとめていきたいと思います。

JVMのトラブル解決のためにやったこと~メモリー/スレッド

@bloody_snowさんのセッション。 JVM周りのメモリ管理について知りたくて参加しました。 立ち見の大盛況だったのですが、Twitterばかり見てしまっていてあまり発表に集中できなかった 汗 Twitterから流れてきたここが参考になるそう。 JVMのツール周りは全く触ったことがないので、機会があれば触ってみたい。

JVM言語とJava、切っても切れないその関係

@yy_yankさんのセッション。 JavaやJVM言語の歴史や関係などをゆるふわなテンションで語られてて非常に面白い方でした。 JavaもJVM言語もお互い良い所、悪い所あってお互い切磋琢磨して成長していこうよみたいなスタンスは非常に好ましいなぁ。

まとめ

初めのjjug cccだったんですが、学ぶことが非常に多くて刺激的なカンファレンスでした。 聞くだけじゃ自分の身につかないと思うので、今回聞いたことや、他の登壇者の方々のスライドを見て、自分の中で解釈する必要があるなと、 この記事を書いていて再度思いました。

最後に、登壇者の方々、ボランティアスタッフの方々、関係者の方々、素敵なカンファレンスありがとうございました！！ また、春にでも参加したいと思います！！

*1:弊社だと、新しい保険商品を開発する際には、既存システムが大きすぎてアジャイル的に開発できない場合などかなぁ