JJUG CCC 2018 Fallに参加してきました。
先週土曜日に開催されたJJUG CCC 2018 Fallに参加してきましたので参加したセッションの簡単なまとめです。 セッション資料などは以下にまとめて頂いております。誠に感謝です。
思考停止しないアーキテクチャ設計
@kawashimaさんのセッションで、到着した時にはすでに会場は満席で、後ろの方で座りながらセッションを聞いていたのでスライドが見れず、ほとんど覚えていないのが正直なところです。。。
ただ、スライドの内容が非常に充実しているので、スライドだけを見てもかなり参考になると思いました。
以下はスライドを見て自分なりの解釈と気になった部分のメモです。
- アーキテクチャとは何か
システム設計における重要かつ変更が困難な意思決定のこと。 - どのようにアーキテクチャを構成するか
品質特性から非機能要求を抽出し、アーキテクチャ設計に落とし込むと同時に、アーキテクチャパターンを利用してアーキテクチャ設計を行う。 - 代表的なアーキテクチャパターン
- アーキテクチャの評価方法
予め定めておいた品質特性シナリオを満たすかどうか。 - アーキテクチャ設計をどう記録し、メンテナンスしていくか
Archetecture Decision Recordによる、コードリポジトリ内に設計上の意思決定のドキュメントを配置しメンテする。 - 設計上の思考停止について
教科書通りに設計を進めたからといってそれで満足してはいけない。
どうしても抜け漏れというものは発生するので、アーキテクチャについては考え続けなければならない。
参考文献が三冊ほど紹介されているので、このスライドを元に目を通したいなと思います。
複雑なドメインに泥臭く立ち向かう
株式会社エス・エム・エスさんのスポンサーセッションです。
複雑なドメインとあってDDDの話かなと思ったのですがそうではなくて、エス・エム・エスさんのビジネスの土台となる医療・介護分野の複雑な法制度を例に、チームにおいてどのようにアプリケーションを設計・開発していくかというお話でした。
私も生命保険分野で業務系アプリケーションの開発をしていた時期もあるので、保険の制度が非常に複雑でどうやって実装するんだ？？といった経験があり非常に共感できるセッションでした。
実装の対象領域（ドメイン）に対する学習は非常に重要で、そのドメインの知識を業務知識と言ったりするのですが、必要な知識というのは非常に膨大であったりします。ただ、その中でも本当に理解しなければならないコアな知識というのは存在しており、それをセッションの中では一本道を見つけると表現しているのかなぁと思いました。
コアな部分を見つけ、実際のコードに落として行く際にも、ホワイトボードを利用してチーム員で徹底して議論しながら知識を深めて実装していく進め方はチーム員で知識を共有しながら実装を進めて行くことができるので非常に良いなと感じました。
またそういう開発を進めていくために、チーム員を少数にしたりレイアウトも工夫していたりで、エンジニアが開発を進めやすい環境を整えているのは非常に好印象でした。
Deep dive Into instanceof
株式会社スマートニュースさんのスポンサーセッションでした。 Javaのinstaceofを利用したコードを何故避けなければならないのか、設計上の観点からではなく、性能面からJavaの内部実装を紐解きながら検証するという内容のセッションでした。
Javaの内部実装について全く明るくないので、セッションの全てを理解できたわけではないのですが、継承を利用していた場合には継承関係を順番に辿っていくため、深い継承関係がある場合にはその分遅くなり、インターフェースを利用していた場合には初回は線形探索を行うものの、結果をキャッシュするため、次回からは素早く動作するという理解をしました。
結局は設計においても性能面においても、単なるアプリケーションレイヤにおいてはinstanceofを利用することは避けるべきだなと思いました。
秒間 200,000 Req/sec をさばく広告入札システムを支えるパフォーマンスチューニング術
ウルシステムズ株式会社さんのスポンサーセッションです。
ソネット・メディア・ネットワークス株式会社さんのLogicadという広告配信プラットフォームのパフォーマンスチューニングについてお話されていました。
広告プラットホーム系のシステムのお話を聞くたびに処理件数であったり、応答時間のシビアさだったり本当にリアルタイム処理が必須になるシステムを開発・運用している人たちは凄いなといつも思います。
今回のセッションですと100ミリ秒（0.1秒）以内でリクエストの受付、処理、レスポンスを返さなければならず、要求される処理性能が非常にシビアです。
ただネットワークのレイテンシというものは距離に比例して伸びていくでしょうし、今現状のどんな技術を用いても光の速度を超えることはできないことを考えると、リクエストを受け付けてからレスポンスを返すまでの処理をどうにかして早くするしかない。
サーバの観点から考えると、スケールアップ戦略（ハードウェア性能の向上）とスケールアウト戦略（サーバの台数を増やす）で対応することは可能ですが、リソース調達コストを無視することはできず、無限にスケールアップ・スケールアウトすることはできません。
なのでアプリケーションの性能を向上させることが必須となり、そのためにはどこがボトルネックとなっているのかを把握することがまず重要です。
ボトルネックの可視化のために、perf + perf-map-agent + FlameGraphというツールを組み合わせてフレームグラフでアプリケーションコードの性能を可視化しているとのこと。 perfとFlameGraphについては知っていたのですが、その結果をフレームグラフで表示することができるperf-map-agentはこの時初めて知りました。
セッション中でも述べられていましたが、パフォーマンスのボトルネックとなる部分はアプリケーションだけではなくて、例えばWebサーバだったりDBだったりとどこにでも発生しうるので、システム全体の把握とどこがネックになっているのかを可視化することは非常に重要だと思いました。
最後に
最初にJJUG CCCに参加したのはちょうど2年前の2016 Fallでした。
恐らく私が初めて参加した技術カンファレンスで、Webエンジニアとして全くの初心者だった頃もあり、雰囲気に呑まれていたのを覚えています。
この2年間で様々な技術に触れ、エンジニアとして知っていること・出来ることというのが増えたなというのは、今回改めて参加してみて実感しました。
ただあの時感じたような技術やコミュニティに対する新鮮な気持ちというのは大分薄れてしまった気がします。
それは自分が知っていることが増えたことで、単に技術というものに慣れてしまっただけのように思えます。
その慣れは最近、自分が感じている停滞感に繋がっていると、このブログを書いていてハッキリと自覚しました。
技術に慣れるのではなく、技術や知識を深め、使いこなし、また新しい何かを作り出していくこと。
2年前の自分はそんなエンジニアになりたかったのだと思い出しました。
改めて自分の目標を再認識することができたことは本当に良かったです。 今後も引き続き参加していきたいと思います。
Japan Container Days v18.12 参加メモ
JapanContainerDays v18.12に参加してきたので簡単な参加メモです。
reannkara.hatenablog.comに引き続き今年で2回目の開催で、しかもセッション期間は2日間という盛りだくさんのカンファレンスでした。参加したセッションは結構あるのですが、特に印象に残った部分をメモっておきます。
Microservices Platform on Kubernetes at Mercari
Keynoteの中でメルカリさんの@deeeetさんのセッション。 なぜメルカリはコンテナとKubernetesを採用したかについて説明されていました。
メルカリさんと言えばモノリシックなアプリケーションからマイクロサービスへの移行を非常に謳っており、安心してサービスをリリース出来る環境を構築することが重要であると認識しているとのこと。
コンテナを利用することでアプリケーションの実行環境が不変であることが担保でき、リリース時に何か不具合があれば安全にロールバックでき、またカナリアリリースもすることができると。
また、Kubernetes自体が高い拡張性を持っており、他のPaaSといったサービスでは実現できない共通プラットフォームを独自で構築できるのではないか、また、周辺エコシステムの成長やいざとなれば自分たちで拡張できることも採用した要因だと仰っていて、非常に目的がハッキリしていると感じました。
何のためにその技術を採用するのか、自分たちも何か技術選定をする際にはちゃんと目的意識を持って採用しなければならないなと痛感しました。
Kubernetes がもたらす 分散システムの脅威との戦い
Wantedlyの@koudaiiiさんのセッション。 全てのプロダクトをKubernetesへ移行したことにより恩恵を受けたが、同時に発生した課題に対してどのように対処してきたか、どのように対処していこうかというセッションでした。
Kubernetesを扱う事自体が複雑なシステムを取り扱うことになりますが、その中でもシンプルさを追求することを諦めないという考え方に非常に共感を得ました。周辺エコシステムの成長が非常に活発であり、魅力的なツールも増えてきていますが自分たちに本当に必要な技術のみを採用するという考え方はわかっていてもなかなか実践できないよなぁと最近痛感しています。 このへんの考え方は最近開催されたKubeConで話されたJulia Evansさんの "ignore most kubernetes ecosystem software" に通じる考え方なのかなとも今振り返って思いました。
他にもKubernetesを導入したことでマイクロサービス化が推し進められたが、マイクロサービスを導入したことにより発生した課題だったり、Kubernetesという複雑な分散システムを扱うことの難しさについて正面から向き合っており、これから多くの企業が直面する課題について説明されていたのではないかと思います。
恐らく自社でも形を変えて直面するであろう課題ばかりで本当に参考になるセッションでした。
Kubernetesが超強力な分散RDBに vitessの真価を大検証してみた
YouTube発祥のOSSであるVitessについてのセッションでした。 VitessとはシャーディングによるMySQLの水平スケーリングのためのクラスタリングシステムであり、Kubernetesに依存しないシステムであること（CNCFにはインキュベートされているみたい）。
アーキテクチャが面白いなと感じて、アプリケーションとMySQLの間にリクエストをプロキシするVTgateというプロセスを配置して、どのMySQLにクエリを発行するべきかなどのメタデータはTopologyというメタデータストアに保管、クエリは各MySQLノード上で稼働するVTtabletというプロキシデーモンが受け付けるという構成となっているみたいです。
私はMySQLを扱ったことはないのですが、これを利用すればアプリケーション側からはどこにデータが存在するのか意識せずに透過的にデータへとアクセスできるのではないでしょうか。本番運用に耐えられるかどうかは検証がもちろん必須ですが、こういった抽象化層を一段設けることによってアプリケーション側の実装負荷を減らすといったアプローチは非常に面白いと感じました。
コードを書くことに集中したい全てのアプリ開発者に贈るKubernetesの話
コンテナ環境で稼働するアプリケーションを実装する際の考慮事項に関するセッションでした。 デプロイ環境の際による設定の保持方法や、ロギング、サービスメッシュ、開発ツールなど、正直、ロギングやサービスメッシュといった分野はアプリケーション開発者に意識させたくない領域だと思っているので、全てのアプリ開発者が知っているべきかと言われると組織に寄るなとは思いました。
ただ、アプリケーションの設定の保持方法については非常に参考になりました。
非コンテナ環境でアプリケーションの設定をする場合には、設定ファイルを各デプロイ環境ごとに保持しており、アプリケーションのビルド時にどの設定ファイルを利用するかを決めていました。こうしてしまうとアプリケーションのリポジトリに同じような設定ファイルを複数保持することになり、保守性が下がってしまうなと感じていました。
同様に、全ての設定内容を環境変数に定義することもしんどいだろうなとも感じており、今までの形式通りファイルで設定を持ちつつも保持する設定ファイルを減らしたいという思いがありました。
セッション中で話されていた、envsubstを利用すればテンプレートファイルは保持しつつも、環境毎に異なる部分だけを差し替えることができるので上記で感じていた課題を解決できるのではないかと思います。
runcだけじゃないコンテナlow level runtime徹底比較
speakerdeck.com speakerdeck.com
前回のContainer Daysで話されていた内容の続きとなるLow Level Runtimeに関するセッションでした。 私自信、コンテナの実行環境を意識するようになったのはKubernetes上でのトラブルが発生した時で、kubeletからDockerコンテナが稼働するまでの一連のプロセスを調べた時に初めてOCIやCRI、runcといったものを知りました。
Low Level Runtimeといっても本当にたくさんあることを本セッションで初めて知り非常に面白かったです。
GitOpsではじめるKubernetes CI/CD Pipeline
www.slideshare.net
GitOpsについては言葉だけは知っていたのですが、実際にどういったものかは知らなかったので非常に参考になりました。 CIツールを中心に据えたデプロイフローをCIOpsと呼び、それに対して、CIとCDを分離し、コンテナイメージのビルドまではCIツールが行い、デプロイはCDツールで行うというのがGitOpsとなります。
実際のリリースフローに関しては各組織によって文化や考え方が異なるので全てがGitOpsであるべきとは言えないとは思うのですが、一つの考え方としてもう少し詳細に調べておきたいなと思いました。
Introducion to CRIU
ペパボの@udzuraさんのCRIUとその応用例に関するセッションでした。
CRIUとはLinux向けに開発された、アプリケーションプロセスのチェックポイント・リストア機能を提供するツールでDockerでも利用されているツールです。実行されていたプロセスのその時の断面を取得することが出来るので、アプリケーションの停止・再起動時の起動時間を短縮することができたりします。
この機能を利用して@udzuraさんは、Haconiwaという独自のコンテナランタイムを開発されており、元ペパボ（現さくらインターネット研究所）の@matsumotoryさんが提唱したFastContainerアーキテクチャ（実際のプロダクトだとロリポップ！かな）でも実際に組み込まれているそうです。
ホスティング事業者が抱える課題を解決するためにアーキテクチャから考え実際に実装し、それを外部へと発信していくという行為自体が只々凄いなと改めて実感しました。
HaconiwaやFastContainerに関する記事はたくさんあると思いますが、自分が見つけたものを貼っておきます。
最後に
あまりこの記事の中では書きませんでしたが、今後Cloud Nativeという言葉がますます認知されていく流れなのかなとなんとなく感じました。 来年からContainer Daysという名前からCloudNative Daysという名前に変わることからもなんですが、今後の関心事がDockerやKubernetesといった今まで中心的な位置に存在していたプロダクトから、それを取り巻く周辺エコシステムに推移していくのではないかという単なる直感です。
それはDockerやKubernetesが廃れるということではなく（もちろんより良いプロダクトが生まれれば廃れるとは思いますが）、それらのプロダクトの存在が当たり前となったときに、今までアプリケーションレイヤーで自前で実装していたものが、周辺エコシステムの発展によって不要になり、より純粋なアプリケーションコード（ビジネス領域に特化したアプリケーション）の実装に向かっていくのではないかという個人的な思いつきです。その現れがIstioといったサービスメッシュではないかと。 それと同時に構成されるシステムはますます複雑になっていくのではないかとも個人的には思っています。
実際にどうなっていくかはわかりませんが、様々な技術が生まれた時に適切な技術を選ぶ、または自前実装できる技術力を持つというのは変わらないと思いますのでこれからも手を動かしながら楽しんでやっていきたいなと思いました。
最後に、このような素晴らしいカンファレンスを開催していただいた関係者の皆様には本当に感謝しかありません。
ありがとうございました！！
Go Conference 2018 Autumn に参加してきました。
だいぶ時間が経ってしまいましたが、Go Conference 2018 Autumnに参加してきましたので簡単にまとめておきたいと思います。
自分は普段Javaでコードを書くことが多いのですが、DockerやKubernetesといったプロダクトでもGoが採用されていたり、実際に触ってみると言語仕様が小さかったり、クロスプラットホームな実行バイナリが簡単に生成できたりで非常に使い心地がいいなと思っていました。
実際にプロダクション環境で利用されている方たちの話を聞いてみたいと思い今回参加させて頂いたわけですが、Goだけではなくてパフォーマンスチューニングの話だったり、gVisorといったコンテナランタイムだったり、マイクロカーネルの実装だったり盛り沢山で非常にエンジニア意識を高めてくれる最高のカンファレンスでした！！
このような素晴らしいカンファレンスを開催していただいた関係者の皆様には感謝の念しかありません。本当にありがとうございました！！（遅い）
以下は簡単なメモと感想です。参考になれば幸いです。
Keynote
Google App EngineのGo Runtimeのメンテナの方のセッションでした。 英語でのセッションだったのでほとんど理解できなかったのですが、gVisorのことを話していたのでドキュメント読んでたりしてました。
gVisorはユーザー空間のカーネル的な位置づけのソフトウェアであり、アプリケーションから発行されたシステムコールをキャッチしてゲストOSであるかのように振る舞うが、すべてのシステムコールを実装しているわけではないそうなので一部実行できないシステムコールもあるとのこと。
このセッションをきっかけにコンテナのランタイムについて非常に興味を持ったのでもう少し詳しく調べていけたらなと思いました。 また、英語でのセッションにもついていけるようにせめて何を言っているかわかるぐらいにはリスニング力もつけたいなと。
Microservices実装ガイド in Go at Mercari
メルカリさんでのマイクロサービスの実装のお話でした。
実装の流れとしては、Protocol Buffersの定義をしてから、サービスの実装をするという流れらしく、プロトコルファイルは専用のリポジトリで管理し、また、マイクロサービスの実装に必要なテンプレートプロジェクトを準備しており、git clone -> rm -rf .git -> git init -> 実装 という開発の流れがある程度決まっているとのこと。
開発者からしてみたらあるサービスの実装を始める時に何も考えずにプロジェクトテンプレートを持ってきて、インターフェースを考えて実装するという流れが決まっているのはやりやすいだろうなと思いました。
OpenCensusによるAPMの実現と、未来
OpenCensusを利用したアプリケーションパフォーマンスの可視化についてのお話でした。
APMとはApplication Performance Managerment の略で、要求されるサービスレベルを維持するためにパフォーマンスの継続的な監視と管理を行うことで、そのためにはデータの収集と可視化する基盤を構築する必要があるとのこと。
APMで取り扱うデータは大きく分けて以下の4つ。
- Tracing
- Metrics
- Logging
- Error Report
これらのデータを収集する際にはアプリケーションコードに収集用のコードを記述しなければならないが、その際に収集・可視化するバックエンドのサービスと密結合になってしまうということを懸念し、OpenCensusを利用する方針をとった。
この話を聞いていてアプリケーションのパフォーマンスの可視化に対するアプローチは大きく分けて2つあるかなと考えていました。
一つはOpenCensusといったコードにデータを収集するコードを書いてバックエンドに送信する方法。
もう一つはエージェントといったデータ収集用のデーモンを利用する方法。（APPDYNAMICSみたいな）
どちらもアプリケーションパフォーマンスを可視化するという目的は一緒なのだけど、採用する組織の目的や文化によってどちらのアプローチを取るか変わってくるだろうなとも思った。また、CNCFといった中でココらへんの実装も増えてきて、選択できるバリエーションが豊富になってくると思うので、目的にあった技術選択ができるようになっておきたいという思いも強くなりました。
アプリケーションとバックエンドサービスの密結合を避けるという観点は自分の中にはなかった発想だったので、そういう気づきを得られたのも非常に良かったです。
Profiling Go Application
自前で実装した画像変換サーバやkubelet、go-swaggerに対してパフォーマンス改善を行った結果やそのプロセスに関するお話でした。
プロファイルを取得し、処理のボトルネックを発見し、コードの修正前後でベンチマークを取得し改善結果を把握するという当たり前のことを当たり前にやることの重要性を再度認識させられたセッションでした。
言葉にしてしまうと簡単そうに思えてしまいますが、プロファイルやベンチ結果といったデータを見てどのように判断するかはプログラマのスキルに依りますし、また、ボトルネックの箇所の特定にしたって、場所を特定してもその実装を見てどこがネックになっているかを判断するのもプログラマのスキルだと思います。
そういった意味で非常に学びのあるセッションでしたし、自分も見習っていこうと思いました。
Reading Source Code of Biscuit
Goで実装されたモノリシックカーネルであるBiscuitのソースコードを読んでみようという内容のセッションでした。 DockerやKubernetesといったプロダクトもGoで書かれていますが、まさかカーネルまで実装されているとは驚きでした。
いきなりLinuxのソースコードを読むのも良いかもしれませんが、カーネルの挙動を理解するためにまずこのBiscuitのコードから読んで見る、というのも良いかなと。
フィードバック制御によるGoroutine起動数の最適化
自分の中の知識が足りずにあまり理論や実装についてはついていけなかったのですが、フィードバックループを回すことにより設定値を最適化していくという考え方は非常に良いなと思っていて、どうにか応用できないかなと考えながら聞いていました。
自律的なシステム=人間の手が入らずともその時その時のシステムの状況を学習することで最適な状態に落ち着くことができるシステム、というのがあれば人間の運用負荷が下がるなとなんとなく考えていて、それにフィードバック制御が利用できるのではないかと。
ただ考えているだけなので、モノクロメガネさんの実装だったり論文だったりもう少し踏むこんで調べていきたいなと思います。
最後に
こういったカンファレンスに参加することの良さって、自分が普段所属する会社だったりコミュニティだったりから離れてみて、また別の視点を得られることだなと参加してみて思いました。自分や会社が抱えている課題に対してこうやって解決しているからそれを応用できないかとか、初めて触れる概念を応用することができないかとか。
だいぶ長くなってしまいましたが、めっちゃ楽しかったのでまた来年行こうと思います。ありがとうございました！！
第26回Elasticsearch勉強会に参加してきました。
だいぶ前の話なんですが、第26回Elasticsearch勉強会に参加してきたので簡単にまとめておこうかと思います。 こういった勉強会の内容ってすぐまとめるべきだと常々思っているのですが、知って満足してしまっているのかなかなか書く気になれないのです。 GoConferenceや本日と明日開催されるJapan Container Daysにも参加しているので、おいおいちゃんとまとめておきたいと思います。
当日の発表は3つあって、そのうち2つの発表資料は以下のリンク先に載ってます。 www.meetup.com
弊社でも最近オンプレ環境のKubernetesでWebアプリケーションを稼働させるという話が出てきており絶賛検証中です。 Kubernetes上でアプリケーションを実行させる場合、CI/CD、監視、メトリクスの収集やログ管理などの仕組みはKubernetes単体では提供しないので、自前で用意してあげないといけません。
私の場合ログ周りの環境を構築するということで、Elastic Stackを利用してアプリケーションログの一括管理などの仕組みを構築し検証してはいるものの、他社さんの事例などを知りたいと思い参加してきました。
こういった勉強会が都内で頻繁に開催されているのをみると、都内に勤めている人は羨ましいなぁと常々思います。
ということで以下当日のセッションの感想です。
(elasticビギナーが考えた）beatsを使った監査サービスの提案
一つ目はサーバの監査ログに関する発表でした。 最初はElastic Stackの存在を知らず、auditd + SCP で実装することを考えていたそうなのですが、Elastic Stack の存在を知りこちらを採用することを検討したそう。 自社でもアプリケーションログの収集に filebeat を利用しているのですが、Beats ファミリーの中に auditbeat というサーバの監査ログを収集するツールもあるそうで、この時初めて知りました。こういった自分が普段あまり関わることない分野に関して知ることができるのも勉強会のいいところだと感じました。 環境構築する際には、 Elastic Cloud というSaaSの利用を検討したそうなのですが、いざKibanaへとアクセスしようとすると、解放できるPortの問題で採用できず。。。ここらへんは、リバースプロキシを立てて、リバースプロキシ経由でKibanaにアクセスすれば良いと思ったのですが、きっと運用やコスト面で出来なかったんだろうなぁと思いました。
Logstashとともに振り返るやっちまった事例ごった煮
二つ目の事例もセキュリティ案件に関する事例でしたが、主にはLogstashの性能面に関する発表でした。 netflowから流れてくるネットワークトラフィック（約20,000/秒フロー!!）をLogstashで受け取る際に発生したデータロスについて、仮説を立て、チューニング（Logstash / カーネルパラメータ）を行うも改善せず、最終的にはサーバのスケールアップ／スケールアウトによって対処したというお話でした。
文章にまとめてしまうと非常に簡単そうに見えますが、自分もアプリケーションのパフォーマンスチューニングをやっていたこともあり、非常に苦労されたんだなと思いました。最終的にはLogstashサーバをスケールアウトすることにより解決を図っていますが、これがあらかじめ用意されていたリソース内でやりきれと言われていたらと思うとぞっとします。
テストの詳細な結果や環境構成等も載せてくれてますので、自社の環境を考える際の指標にもなるなと思い非常に参考になる発表でした。
ElasticsearchのQueryが遅い時のトラブルシューティング
クエリ遅いよ！！と言われた時のトラブルシューティングの方法についての発表でした。 Profile APIやProfiling Toolsが用意されていることを初めて知りました。 Elasticsearchもだいぶ奥が深いのでまずは公式ドキュメントをざっと眺めないとなぁと思いました。
凄いざっくりとした感想でしたが、改めて他社さんの事例を聞くことができて非常に学びある時間でした。 遅くなりましたが、主催者並びに発表者の方々、会場を提供してくださったFJCTさんには感謝しかありません。ありがとうございました！！
DockerのRedisと非コンテナRedisのベンチマーク比較
これはなに？？
Kubernetes上で稼働するRedisの性能が思った以上に出ないと言われ、Redis単体のベンチマークやアプリケーションのパフォーマンステストを実施している。
その際にふと、Dockerのコンテナ上で稼働するRedisと非コンテナプロセスのRedisではどれくらい性能差がでるのか気になったので、自宅のPCを利用してベンチマークを取得し比較してみた。
ローカル環境かつ、結果もざっくり把握しているのであまり正確ではない。
実行環境
- 実行ホスト
- Docker
- バージョン 18.05.0-ce
- Redis
- バージョン 4.0.11
- Docker Image redis:4.0.11
実行方法
- Docker
- ブリッジネットワーク（デフォルト）
- docker run --rm -p 6379:6379 redis:4.0.11
- ホストネットワーク
- docker run --rm -p 6379:6379 --net=host redis:4.0.11
- ブリッジネットワーク（デフォルト）
- 非コンテナ
- make実行後、srcフォルダで./redis-serverを実行。
計測方法
redis-benchmarkを利用して計測した。
redisのプロセスとredis-benchmarkのプロセスの実行CPUをあまり意識せずに計測してしまったので、本当ならCPUを指定して実行するべきだったかも。
3回ずつbenchmarkツールを実行して、ざっくり振れ幅が少ないことを確認して計測を終えている。
比較結果
実行結果はここにおいている。
最初、デフォルトのブリッジネットワークで実行していたのだけど、非コンテナのベンチマーク結果と比較して1/3程度の結果になっていた。
ある程度の性能差は出てくるとは思っていたのだけど、単なるプロセスにすぎないコンテナでそんなにも差が出てくるのはおかしいと思い、試しにホストネットワークモードでも計測してみた。
結果、なんとなくこんなもんかなーくらいの性能差になった。
感想
Dockerのデフォルトブリッジを介すことによる性能劣化がこんなにも生じるのか、ちょっと自身が持てないがNATによる影響は少なからずあるのだと思う。
今回はRedisでやってみたけど、シンプルなアプリケーションで試してみたらよりわかりやすくなるかもしれない。
仕事でRedis周りを利用したアプリケーションの運用をすることになりそうなので、併せてRedis周りの知識を身に着けていきたい。
ざっくりと以上。
Japan Container Days v18.04に行ってきました。
Japan Container Days v18.04に参加してきました。
チケットが事前に完売していたり、当日の盛況具合からコンテナやKubernetesなどの技術への注目度がますます増してきたのだなと実感しました。
以下、自分が聞いたセッションの振り返りです。
スライドのまとめはこちらの記事でまとめてくださっています。
サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術
AKEというサイバーエージェント社で独自に実装しているコンテナ基盤の紹介をしていた。
自社で独自のコンテナ基盤を実装するという発想がそもそもなかった自分は純粋に凄いなと思ったし、Kubernetesなどの内部実装を知ることで、自分の好きな通りにプラットフォームを構築できるというのは楽しそうだとも思った。
Kubernetesを利用するだけではなくて、内部動作を深く学んでいこうと思えた。
マイクロサービスアプリケーションとしての機械学習
mercari社の機械学習を利用したサービスの展開とその運用についてのセッションだった。
私自身、機械学習についてはほとんど知らなかったのだけど、スライドに記載ある通り
mercari社での機械学習システムに求められるシステム要件が非常にハイレベルなものであり、かつ、それを1週間ほどで準備するSREの技量の高さに非常に驚きを覚えました。
また、機械学習を利用したサービスの運用は、Webサービスの運用とは異なった側面を持つというのは自分にとっては新しい発見で、そのサービスにあった運用を考えなければならないのだと考えさせられました。
"Yahoo! JAPANのKubernetes-as-a-Service"で加速するアプリケーション開発
KaaS（Kubernetes-as-a-Service）について話していたのが特に記憶になっている。
Kubernetesを利用することで、コンテナ化されたサービスの運用にはメリットが生じるが、Kubernetes自体の運用が新しく発生してしまう。
これはKubernetesだけに限った話ではないと思っていて、現状の課題を解決するために新しいツールを導入したら、そのツール自体の運用が発生するというのはよくある話だと思っている。
そこでKubernetesの拡張機能を利用して、Kubernetes-as-a-Serviceを実装したとのこと。
ここでもKubernetesの内部実装や機能をよく知ることで、自分たちのソリューションを実装するという話が出てきて、尚更Kubernetesについてよく知りたいと思った。
Cloud Native Apps入門
CNCFではCluod Nativeなアプリケーションは以下の3つの要素を備えていると明記している。
Charter - Cloud Native Computing Foundation
- Container packaged.
- Dynamically managed.
- Micro-services oriented.
また、Cloud application maturityといったものもあったりする。
GitLabやGitHubの事例も紹介されていたので、アーキテクチャの部分とかあとでちゃんと見てみたいと思う。
Spinnakerを利用したKubernetesへの継続的デリバリ
Spinnakerの紹介セッションだった。
コンテナ環境のCI/CD周りって、デファクトが確立されていない分野っていうのは感じている。
CI/CDツールの選定や、Kubernetesを利用するのであればYAMLの管理やデプロイ方法、HELMを利用するかなどいろいろ考えなきゃいけない。
Kubernetesの運用設計ガイド
スライド上がったら別途まとめたい。
Kubernetesの設計思想を踏まえた上での運用設計であったり、自律的な組織を目指すといった部分は非常に共感できた。
運用設計の具体的な部分については、ベストプラクティスと被るところが多かった気がする。
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法！
DockerやKubernetesだけじゃなくて、PasSやServerlessも視野に入れながら適切な技術を選択するのが大事だよねっていうセッションだった。
DockerやKubernetesを導入することで、アプリケーションの実行や管理っていう側面はある程度楽になったかもしれないけど、その分知らなければいけない領域が増えたり、別途オペレーションが必要になったりと、意外とやることだったり気にしなきゃいけないところだったりが増えているのも確かだと思う。
Fluentd and Distributed Logging in Container Era
@repeatedlyさんのセッション。
セッションが20分だったからなのか、めっちゃ早口だった。
隣の人が今日一何を言っているかわからないと言っていたのが印象的だったが、コンテナ環境のロギング周りのこと知っていないとついていけないなとは感じた。
同名のタイトルでTreasure Data社のブログがあるのでそっち見てみても良いかも。
全体的に参加人数とキャパが見合ってなかった気がするけど、最高のカンファレンスでした。
運営の方やスピーカーの方には感謝しかありません。
また12月にもあるみたいなので、そちらも是非参加したいと思います。
「本を読む本」読書メモ
最近、本を読んでいても漠然と読んでいるだけで、何も身についていないと思うことが非常に多いので、本を読む本 (講談社学術文庫)を読み返している。
本書では読書には４段階のレベルがあるという。
- 初級読書
- 点検読書
- 分析読書
- シントピカル読書
初級読書については、基本的な読み書きができれば良いとのことなので、主に点検読書についてまとめておく。 分析読書、シントピカル読書については本書をまだ読みきれていないので、また機会があればまとめておきたい。
点検読書
点検読書には2つの段階があり、それは拾い読みと表面読みである。
点検読書を通じて読み手は以下の問いに答えられなければならない。
- その本は何について書いたものであるか
- その本はどのように構成されているか
勝手に尊敬しているid:y_uukiさんは、この段階で「この本を読んで達成したいことは何か」という問いも追加されており、この点は真似したいと思った。
全体把握というのは、書籍「本を読む本」でいうところの読書の第2段階「点検読書」のうち組織的拾い読みに該当する。さらに同著には、積極的読書のためには質問をすることが重要と書かれており、点検読書の段階では、「全体として何に関する本か」、「何がどのように詳しく述べられているか」に関する質問に答えるとよい。自分の考えでは、「この本を読んで達成したいことは何か」という質問にも、点検読書の間に答えられるとよいと思っている。
書籍「詳解システム・パフォーマンス」 下読み - ゆううきメモ
拾い読み
これから読もうとする本が、本当に読むに値するか判断するための読書方法。以下の段階を経て判断する。
これらの段階を経て、上記に述べたような問いに答えていく。
- 表題や序文を読む
- 本の構造を知るために目次を調べる
- 索引を調べる
- カバーに書いてある謳い文句を読む
- 議論の要と思われる部分を読む
- ところどころ拾い読みする
表面読み
とにかく通読してみる読書方法。
理解できない部分や、知らない単語、脚注などは一切無視してとりあえず読み進めてみる方法。
点検読書を行うことでその本の全体像を掴むことができる。
また、「本を読んだ後に何を達成したいのか」という問いを立てることで、自分が身に着けたいことを明確にすることができる。
「本を読む本」を点検読書する
点検読書についてまとめたので、本書を点検読書してみる。
何について書かれたものか
読書の方法論について書かれた書籍である。
読書をする際に自ら問いを立て、知識を得て、思考し、自分の立てた問いに答えられるようになることで内容を自らのものにしていく方法論について書かれている。
どのような構成になっているか
第一部で読書に必要な姿勢（自ら問いを立て、答える）と読書の段階について述べ、第二部、第三部、第四部では各読書の段階における方法論について述べている。
達成したいことは何か
読後に何を身につけることができたか、明確に述べられるように読書の方法を身につけたい。
そういう意味では、点検読書の方法論を知り、次に読む本の読み方を身につけられたのではないかと思う。
