あさのひとりごとスマートフォン用の表示で見るあさのひとりごと3日坊主にならないように、全力を尽くします。記事は個人のひとりごとです。所属する組織の意見を代表するほど、仕事熱心じゃないです。HOMEBooksProfileこの広告は、90日以上更新していないブログに表示しています。仕事も大掃除も終わってないですが、2018年が終わろうとしています。2018年、良い1年でした!5月に転職5月までは、TISに在籍し、その後Microsoftに転職しました。TISに不満があったわけではなく、むしろ大変居心地がよく、人間関係も業務内容も報酬もとても満足していました。R&D部門だったこともあり、技術的に大変高いレベルの同僚ばかりに囲まれていたので、非常に恵まれた環境でした。転職した理由は、、、、パブリッククラウドは電気や水道のような存在になるはずだという確信があり、もっとクラウドを多くの人に知ってもらいたいという思いから、AWSの本とGCPの本を執筆させていただきました。多くの人に知ってもらうだけでなく、より多く広く使ってもらうため、パブリッククラウドベンダーに転職しようと決めました。2社応募し、どちらからも内定をいただき、Microsoftに決めました。Mindsetをもって猛追するほうが、今の私には適しているかなと思ったからです。内定を辞退させていただいた企業のマネージャからは、お断りしたその日に直接お電話をいただき、同じ志を持つことを改めて共有させていただきました。私にとっての大きな大きなテーマでもあります。同人誌1冊イベント登壇3回2018年4月にDocker本の改訂版を刊行、おかげさまで初版=>第2版=>韓国語版を出させていただきました。休日夜間にこつこつ書き続けていた「しくみがわかるKubernetes」を2019年1月に刊行する予定です。今回は担当の章をぱっくり分けて並列分散執筆スタイルをとりました。青焼きが終わり、あとは本屋さんに並ぶのを待つだけのはずです。8の本を地味に書き始めて、はや6冊目になります。ちりもつもれば、たくさんのちり。来年もまた書かせていただく予定です。外資企業に転職したのもあって、環境に慣れないことも多く、圧倒的にアウトプットが少ない1年でした。いえ、無茶苦茶な英語でも恥ずかしくなくなるほどメンタルが鍛えられましたし、オンライン会議は当たり前、なにより事務処理や執務環境が最適化されていて快適、社食のカレーもソフトクリームもおいしい、華道部に入ってロールも経歴も違う他部門の人とも仲良くなったり、わりとゆるゆる~っとストレスなく生きている感じです。同人誌はどうしても2冊書きたかったのですが、秋の技術書典の日に用事があって1冊のみになってしまいました。2018年新しくチャレンジしたことAzureの勉強これにつきます。今のポジションが技術営業で、ゼネラリスト的な広い業界知識を求められるので、パートナーと協業スキームを検討したりなどで、営業の実践スキルは上がったかなと思います。あと、製造系に非常に強いパートナーのプリセールスのみなさんと仲良くなり、IT技術だけでなく組み込み系やHPC・CADなどの知識も教えてもらえるリレーションができたのは本当に良かったです。私は技術ロールのキャリアに約10年のブランクがあるため、IaaSをメインとしたApp&インフラ領域の技術では、いつまでたっても周回遅れのままです。実務経験や現場でのノウハウ、、のようなものを求められると、その時点でアウトです。Azureなどまだまだ取り組んでいる人が少ない領域に関しては、できるできないにかかわらず、だれよりも積極的に手を挙げていくようにしています。Spark)にめっちゃ詳しい人で、いろいろ教えてもらえるので、本当にラッキーな環境です。全体的な反省点としては、2017年に比べてコードを書いたり環境を作ったりする時間が激減し、技術的なスペシャリティを伸ばすということがほとんどできませんでした。現時点の予定ですが、、、いくつかパートナーとの新しいソリューションを作っていければと思っています。ここでは詳しくは書けませんが、おもしろくなっていきそうです。どの案件でも技術的なスペシャリティを伸ばすため、意図的に時間をとってきちんと手を動かして技術習得したいと思っています。あと、同人誌は必ず2回出したい!自分が好きなものを好きなようにつくる、という行為そのものが好きなので、2019年もプライベートで没入できるなにかができればいいなと。体が丈夫でないというのもあり、2019年はいつくたばっても後悔のないように「やりたい!」とおもったことはすぐやろうと思ってます。22:362018年にがんばったことと2019年のやっていき💪Tweet広告を非表示にする2018-04-10Kubernetesで実際のメモリを超えるコンテナアプリを動かすと、どうなるか?Kubernetesは、コンテナアプリケーションをデプロイするためのオーケストレーションツールです。Kuberenetesは分散環境におけるスケーラブルなコンテナ実行環境をつくるための、さまざまな機能が提供されています。Googleが開発したBorgをもとにOSS化したものですが、今日ではマイクロソフトや(ryKubernetesをつかうとステートレスでマイクロサービス的なアプリケーションを1日に何度もデプロイでき、スパイクアクセスがきても水平スケールが容易なので、大規模Webシステムでスケーラブルな基盤を作れる、というのは広く知られています。Requests」という機能があり、これはPodをデプロイする時に必要とするリソース(CPU/メモリ)を指定できるものです。これにより、Kubernetesクラスタのリソースの使用率を高め、効率よくアプリを稼働させることができるのも、うれしさの一つです。Kubernetesではコンテナが使用するコンピューティングリソースを明示的に要求したり制限をかけたりすることができます。Request)ついて、コンテナアプリが使うメモリを明示的に要求するとクラスタ上でどういう動きをするのか?メモリをたくさん使う別アプリが邪魔してきたとき、きちんとシステムは動作するのか?が気になり、簡単な検証をしてみました。実験環境AzureのKubernetesのフルマネージドサービスであるAKSを使います。公式サイトをもとにKubernetesクラスタを構築しました。Docsここでは、次の構成のクラスタで実験します。MasterもNodeもkubernetes1.9.6で検証しています。VMの「Standard_D1_v2」をNodeにつかっています。Standard_D1_v2は1台当たり約3.3GBのメモリが使えます。念のため、次のコマンドで確認します。3399192KiNode上ではkube-proxy等も動作しているため、Podを1つも動作させていない状態でも、223M/499Mのメモリを使用しています。Requestの動きを確認します。コンテナに制限をかけるには[resources:]-[requests:]で値を指定します。2」つまり2つのPodがKubernetesクラスタ上にスケジューリングされる定義になります。1.5Gi]を指定します。対して「このPodにあるNginxコンテナは1.5Giのメモリ必要だからよろしく!」を宣言しています。1.5Giこれを次のコマンドを実行してクラスタ上でリソースを作ります。createdPodがそれぞれNode1とNode2で1つずつ動いています。aks-nodepool1-12354740-1絵で描くとこんな感じ。起動しているNginxは何も仕事をしていないので、実際のメモリ使用量はほとんど増えていません。15%要求されたメモリが実際のメモリを超えるとどうなるか次のコマンドを実行して、Podのレプリカ数を2から3に増やします。scaledNode1に2つのPod、Node2に1つのPodが動いています。定義ファイルで要求した総メモリ量は、実際のクラスタのメモリ量を超えていません。aks-nodepool1-12354740-1絵で描くとこんな感じです。次はレプリカ数を3から4に変更します。scaled4つ目のPodである「reqest-exp-fgrpn」はどこのNodeでも起動せず「Pending」になっているのが分かります。aks-nodepool1-12354740-1またまた絵で描くとこんな感じ。しつこいですが、実際のメモリ使用量はほとんど増えていません。実際はアイドル状態なのに4つ目のPodはスケジューリングされていないということをいっています。これは、4つ目のPodを配置しようとしても、メモリの空きがマニュフェストで定義した「1.5GB」を確実に確保できるスペースがNode上にないからこのような状態になっています。Requestsは、Podに対して指定したリソースが使えるように保証する仕組みです。この値はPodをNodeにスケジューリングするときに使われます。Requestsを指定したコンテナを含むPodを作成すると、KubernetesのスケジューラーはNodeを選択して実行します。その際、各Nodeには、各リソースタイプの最大容量をもっていてスケジューラは、各リソースタイプに対して、スケジュールされたコンテナのリソース要求の合計がノードの容量よりも少ないことをチェックします。実際のメモリ使用率は非常に低くても、スケジューラはチェックが失敗した場合はNodeにPodを配置しません。Requestsの設定はPodではなく、コンテナに対して行われます。今回指定したメモリはバイト単位で設定でき、E/P/T/G/M/K(Ei/Pi/Ti/Gi/Mi/Ki)のいずれかを使用して、メモリを整数または固定小数点整数として指定します。今回のケースでは、実際のメモリがたくさん空いているにもかかわらずPodは配置されませんでした。Nodeのメモリの最大容量は分かっているので、あらかじめ基盤の方式設計段階でNodeにぎゅうぎゅうにPodがスケジューリングされることを避けることができます。今回は同じサイズのNodeで検証しているのできちんと2台でスケジューリングされそうな気もしますが、なにか見落としているのかもわかりません。いうわけで、ソースコードをきちんと読みたいと思います。(理由をご存知の人がいればおしえてください)追記:まかべ@マイクロソフトさんから教えてもらいました!ご指摘通り、Node1だけheapsterが動いておりました。Requestsについてですが、片方のNodeだけheapsterが動いていて非対称なので、その分メモリが296Mi足りなくて4つめのPodが行儀よく待っちゃってるかも。heapster分を考慮してPodごとのRequestを1.3Giにしたら、4つ動きました。Requests」で宣言した分のメモリをきっちり確保してPodをスケジューリングしているのが分かりました。Requestsは、実際のメモリの使用量ではなく、クラスタに割り当てられているリソースに基づいていることもわかりました。Requests」の宣言なしにメモリをたくさん使う野良Podががんがんデプロイされたらどうなるでしょうか?まず実験のため、次のようなメモリを1.0GBつかうDockerイメージを作ります。これをビルドしてmem-stressという名前のDockerイメージを作ります。Registryなどのレジストリで公開します。次にこのDockerイメージを動かすPodを起動するReplicaSetのマニュフェスト(mem-stress.yaml)を作ります。5」と定義しています。クラスタには理論上各Nodeに3.5GBずつメモリがありますので、ざっくり5つくらいの野良Podを起動してみます。Request)を指定していないことです。どれだけリソースを使うコンテナが入ったPodなのか一切知らないのです。createdなるほど。「mem-exp-xxx」のPodは4つしか起動せず、うちいずれかの1つはCrashLoopBackOff―Errorで再起動を繰り返しています。aks-nodepool1-12354740-1絵にかくと次の感じです。Podのログを確認するとエラーが出ているのが分かります。39sシステム全体のメモリ使用量はきちんと上がっています。77%これを、40分ほど放置します。その間に夕飯のしたくを。aks-nodepool1-12354740-1何が起こっているか、よーく見てみます。1.Node1にスケジューリングされた野良Pod3つ「mem-exp-6dcgh」と「mem-exp-dnwjk」と「mem-exp-x9gxl」はPodを稼働させたくても実際のメモリが足りないため、うち1つのいずれかが再起動を繰り返し「CrashLoopBackOff」のステータスになっています。2.Node2にスケジューリングされた野良Pod2つ「mem-exp-grxvz」と「mem-exp-v5j29」は再起動されることもなく順調に稼働しています。3.マニュフェストでメモリの使用量をあらかじめ宣言したPod4つ「reqest-exp-9kztw」は再起動されることなく3つが稼働中、そして空き容量待ち「reqest-exp-fgrpn」はPenddingでお行儀よく待っていること分かります。Requestsでメモリを記述しないと、「Podがいつメモリ不足で終了されても構わない」という意味になります。(QoS)クラスを提供しています。Limitsの2つから次の条件でclassが決まります。describeでできます。「mem-exp-96vdn」のQoSを確認するときは次のコマンドになります。BestEffortちなみにpod内に複数のコンテナが存在する場合はまず各コンテナに上記のルールに従ってQoSを割り当てます。全てのコンテナがBestEffortならPodのQoSはBestEffortとなり、全てのコンテナがGuaranteedならPodのQoSはGuaranteedになるとのことです。いずれの条件にも当てはまらない場合BestEffortになるとのことです。Requestsを指定したPodのQoSは「Burstable」、なにも指定しない野良Podは「BestEffort」が設定されていました。Nodeのメモリ上限に達した場合、どういった判断でkillされるかKubernetesクラスタは魔法の箱ではないので、実際のメモリを超えるアプリは実行できません。今回の検証のNode1でなにがおきていたかというと。Kubernetesでは、QoSに従ってどのPodのコンテナがkillされるか決まります。優先度が低く最初にkillされるのはBestEffort、つぎにはBurstable、最後にGuaranteedがkillされます。processがメモリを必要とした場合のみkillされます。scoreのよってどのプロセスをkillするかを比較して決めているようです。適当にkillしているわけではなく、Kubernetesはちゃんと忖度しながらkillしています。今回の検証では、メモリが足りていないNode0上で、優先度の低い野良Podがkillされ、再起動されていました。この再起動のルールも、実はとても興味深い処理方式で動いています。こちらは後日別ブログで。まとめKubernetesでは、アプリケーション(コンテナ)が使うメモリに制限をかけると、クラスタ上の理論的なリソースが配分されてPodがスケジューリングされることがわかりました。Podの優先度が高くなり、クラスタの実際の使用メモリが多くなったときも、killされる可能性が低くなることが分かりました。検証していませんが、ServiveやIngressでサービスディスカバリーを定義しておけば、今回のケースではいずれかのPodは動いているはずですので、クラスタ外部からのアクセスをみてみると、サービスが正しく動作している状態を維持できているはずです。Limitsを与えたときの動きや、CPUに関しても後日ひまを見つけて検証してまとめてみたいと思います。いうわけで、クラウドのKubernetesマネージドサービスを使うと、クラスタそのものの構築やMasterのメンテはお任せできますので、分散基盤のめんどうがみられるレベルのインフラエンジニアがいなくても、快適なデプロイ環境を作れますが、一方、、、知識としてのインフラ技術は、ある程度勉強しておかないと、障害時に中でなにがおこっているのか、だけでなく適切な基盤方式設計ができない、ということにもなります。難しいですが勉強だいじ。17:18Kubernetesで実際のメモリを超えるコンテナアプリを動かすと、どうなるか?Tweet広告を非表示にする2018-04-02Kubernetesはクラスタで障害があったとき、どういう動きをするのかKubernetesは、コンテナアプリケーションをデプロイするためのオーケストレーションツールです。Kuberenetesは分散環境におけるスケーラブルなコンテナ実行環境をつくるための、さまざまな機能が提供されています。Googleが開発したBorgをもとにOSS化したものですが、今日ではマイクロソフトやRedHatも積極的に開発に加わり、非常に早いスピートで機能拡張していて、追いかけるのも大変です。Kubernetesの大きな特徴は宣言的設定にあります。この宣言的設定とは、イミュータブルなインフラを作るための基本的な考え方で、「システムのあるべき姿」を設定ファイルにて宣言する!という考え方です。Kubernetesは設定ファイルに書いたとおりのインフラを維持するように設計されています。Kubernetesはコンテナを「Pod」という単位で管理します。このPodをKuberenetesクラスタ内でどのように稼働させるか、を維持する機能が「ReplicaSet」です。ReplicaSetをつかうと、テンプレートで定義した構成のPodが常に稼働している状態をつくれます。いうことは、、、、、たとえ何らかの理由でPodに障害が発生しても、なにも対処しなくても自動復旧するはずよね!!!が本当かどうか確かめるべく、AzureでKubernetesクラスタを構築し、ReplicaSetの簡単な実験をしてみます。実験準備AzureのKubernetesのフルマネージドサービスであるAKSを使います。公式サイトをもとにKubernetesクラスタを構築しました。Docsここでは、次の構成のクラスタで実験します。実験1:クラスタ内のコンテナが異常終了したらどうなるか?まず、Nginxが動くたけのシンプルなPodを構成するために次の定義ファイルを作成します。ちなみにKuberenetesのPodはいくつかのコンテナをまとめたもので、今回はPodに1つのコンテナを入れたものを使います。nginxKubernetesでは定義ファイルはマニュフェストと呼ばれ、YAMLまたはJSONで記述します。このマニュフェストで宣言した構成の意味をざっと図解すると、次のとおりです。このマニュフェストのポイントは以下の指定で、これはKubernetesクラスタ内に常に5つのPodを稼働させておくということを宣言しています。5次のコマンドでreplicaset.yamlに定義したReplicaSetをクラスタ上に構成します。podsコマンドで行います。「宣言」した通り、5つのPod(コンテナ)がクラスタ上で起動しています。次の例では「replicaset-exp-58bp7」~「replicaset-exp-hh8qb」という名前のコンテナが起動(Running)しているのがわかります。14sこれら5つのPodが2台のNodeにどう配置されているかを確認します。今回の実験ではNode0(aks-nodepool1-12354740-0)とNode1(aks-nodepool1-12354740-1)に次のようにpodが配置されていました。Node1図であらわすと書くと次のようになっています。1つのPodをわざと削除してみるとどうなるかここでNode1上で稼働しているPod「replicaset-exp-hh8qb」をPodを以下のコマンドで削除します。replicaset-exp-hh8qbクラスタ内のPodがどういう状態であるかを次のコマンドで確認します。」が新しく生成されています。現在の状態を図でかくと次のとおりです。結果1:クラスタ内のコンテナアプリが異常終了したらどうなるか?実験したところ、マニュアルに書いてある通り、コンテナアプリが動作するある1つのPodが何らかの障害で利用できなくなったときも、ReplicaSetのマニュフェストで指定した、レプリカ数=5になるよう、新しい別のPodが自動で1つ生成されました。KubernetesのReplicaSetは、設定ファイルに書いたとおりのインフラを維持するように動作することがわかります。Healing)機能といいます。だれがいったいPodを復活させたのでしょうか?をみていきます。Kuberenetesの主なコンポーネントたちKubernetesは分散環境でサーバ群が協調してそれぞれの処理を行います。このかたまりのことをKubernetesクラスタと呼びます。Kubernetesで動作しているサーバおよび主なコンポーネントは次のとおりです。MasterKubernetesクラスタ内のコンテナを操作するためのサーバです。kubectlコマンドを使ってクラスタを構成したりリソースを操作したりする際は、マスターサーバがコマンドからのリクエストを受け取って処理を行います。複数台からなるKubernetesクラスタ内のノードのリソース使用状況を確認して、コンテナを起動するノードを自動的に選択します。Kubernetesがオーケストレーションツールと呼ばれるのも、このマスターサーバが複数台からなる分散したノードをまとめて管理することで、あたかも1台のサーバであるかのようにふるまいます。各コンポーネントからリソースの情報を受け取りetcd上に格納します。他のコンポーネントはこのetcdの情報にkube-apiserverを介してアクセスします。このkube-apiserverにアクセスするには、GUIツールやkubebtlコマンドを使います。アプリケーション内からkube-apiserverを呼び出すことも可能です。kube-apiserverは認証/認可の機能も持っています。■kube-schedulerkube-schedulerはPodをどのNodeで動かすかを制御するコンポーネントです。kube-schedulerは、ノードに割り当てられていないPodに対して、Kubernetesクラスタの状態を確認し、空きスペースを持つNodeを探してPodを実行させるスケジューリングを行います。■kube-controller-managerkube-controller-managerはKubernetesクラスタの状態を常に監視するコンポーネントです。定義ファイルで指定したものと実際のNodeやコンテナで動作している状態をまとめて管理します。Node実際にDockerコンテナを動作させPodを稼働させるサーバです。AKSでは仮想マシン(VM)で構成され、通常は複数用意して、クラスタを構成します。ノードの管理は、マスターサーバが行います。何台ノードを用意するかは、システムの規模や負荷によって異なりますが台数が増えると可用性が向上します。kubeproxyというコンポーネントも動作しますが、説明は別ブログで。■kubeletkubeletは、Podの定義ファイルに従ってコンテナを実行したり、ストレージをマウントしたりするエージェント機能を持ちます。Serverに通知します。etcdKubernetesクラスタの構成を保持する分散KVSです。Key-Value型でデータを管理します。Serverから参照されます。Podのオートヒーリング機能クラスタの状態監視は、Masterのkube-controller-managerが行います。このkube-controller-managerには次の機能があります。controlleretcこの中でPodの状態はReplicationManagerが監視しています。実際に稼働しているPodの数とetcdで管理しているマニュフェストファイルで定義したreplicasの数が一致していない場合、Podの数を調整します。GitHub新しく生成されたPodは、kube-schedulerによって適切なNodeにスケジューリングされます。分かりやすく勉強になりました!こちらをぜひ!qiita.comこの記事で解説されているように、kube-schedulerによって最適なノードにPodがスケジューリングされます。実際にノード上にPod、つまりDockerコンテナを実行させるのは、kubeletが行います。kubeletは自Nodeに割り当てられたPodのスケジューリングに従い、必要な数のPodを立ち上げます。このようにKuberenetesでは複数のコンポーネントがいい感じで協調しながらクラスタを維持しているのが分かりました。実験2:クラスタ内のサーバ(VM)が異常終了したらどうなるか?前の実験では、Pod(コンテナ)のアプリケーションが停止したときの動きをみましたが、次はKubernetesクラスタを構成するサーバ、つまりNode障害がおこったときにPodがどうなるかを確認します。クラスタを構成するサーバが、物理的にぱーーーんっと逝ってしまったときを想定しています。注意:これは実験です。drainコマンドでNode上のPodを安全に退避させてから停止をします。本番機で実験しないようにお願いします。意図的にNode0で障害を起こしてみるNode0には3つのPodが起動した状態ですが、ここで強制的にNode0(aks-nodepool1-12354740-0/10.240.0.4)となっているVMを停止します。nodesコマンドで確認すると「NotReady」となり、KubernetesのMasterから利用できない状態になっていることが分かります。podsコマンドを実行すると、8つのPod確認できます。うち5つが稼働(Running)し、3つのPodが不明(Unknown)な状態であることがわかります。40sこれらの8つのPodがNodeにどう配置されているかを確認します。Node1図で書くと次のとおりです。!きちんとKubernetesクラスタ内に5つのPodが稼働した状態を維持しています。Podのたどった運命は、次の3つのパターンがあります。それぞれログを確認します。1.もともとNode0で稼働していたPod(replicaset-exp-58bp7)node-controllerによって、障害のあるNode0から立ち退き(NodeControllerEviction)されています。Node1で稼働していたPod(replicaset-exp-6mj5z)Podに変更なしです。container3.新しく生成されたPod(replicaset-exp-8p6xz)default-schedulerから指示を受けたNode1のkubeletによって新しいPodが生成されています。container結果2:クラスタ内のサーバ(VM)が異常終了したらどうなるか?1つのNodeが何らかの障害で利用できなくなったとき、別の正常に動作しているNode上で、ReplicaSetのマニュフェストで指定したレプリカ数=5になるよう、Podが自動生成されました。障害が発生したNodeで稼働していたPodがふたたび再配置されるわけではなく、新しい別のPodが正常なNode上に生成されることが分かりました。いうわけでやはりReplicaSetは、たとえNode障害が発生しても設定ファイルに書いたとおりのインフラを維持するように動作するよう実装されていることがわかります。ControllerがNodeの管理を行います。Controllerは、Kubernetes内部のノードリストを最新の状態を保持する役割があります。Controllerは該当のNodeを、クラスタのNodeのリストから削除します。Controllerはノードの状態を監視します。Controllerがハートビートを受信しなくなったときなど)に、NodeStatusのNodeReadyをConditionUnknownまたはConditionFalseに更新し、ノードからすべてのPodを取り除きます。ControllerがノードリストからNode0を外したため、正常に動作しているNode1にReplicaSetで定義したreplicasの値を維持するようPodが配置されました。ReplicaSetは障害があったPodと同じ状態のものではなく、別の新しいPodが新規作成されるということを、きちんと理解しておく必要があります。まとめKubernetesは、分散環境でも高い耐障害性を保持するしくみを持っていることが確認できました。維持できないケースも考えられましたので、脳内を整理して別途ブログにまとめます。読みました!クラウドサービスを使うと、あっという間にアプリケーションがローンチ出来る時代になりました。良い世界に向かっています。あるがゆえに、自社のサービスを差別化しビジネスにしていくのが難しく、深層学習のような高度な数理を必要とするインテリジェントなアプリや専門性の高い業務知識を要するアプリでないとなかなかマネタイズが。いうとこもあり、エンジニアは勉強すべきことが山ほど増えてきています。そんなわけなので、アプリのインフラの運用にかかる作業はクラウドに丸投げし、可能な限り自動化しないと命がいくつあっても足りません。サービスが停止するとビジネス損失も大きいので、監視だけはしっかりしたい。毎日定時に帰り土日はゆっくりまったりしたい。Mackerelは、はてなが提供している国産サーバ監視SaaSです。システム監視はプロのノウハウや技術が必要な部分がどうしても多いわけなので、SaaSを使うのがおすすめです。読ませていただきました。MackerelとはなにかMackerelは、はてなブログはじめはてなの自社サービスから生まれた監視サービスです。サーバ=「鯖」=Mackerelというダジャレ乙というところからはじまり、Mackerelのコアコンセプト/提供機能/基本アーキテクチャ/動作環境などがコンパクトにまとまっています。Mackerelは、Push型アーキテクチャを採用しており、監視対象ノードにmackerel-agentを動作させてメトリックスを収集する構成です。MackerelをはじめるMackerelのサインアップのしかたから始まり、管理画面の見方、収集できるメトリックの種類などが解説されています。なんと「カラー!!」うらやましいです。監視するここでは、具体的にMackerelでサーバを監視する手順が紹介されています。メトリック監視で監視ルールをどう設定すればよいかや、クラウドサービスの監視などでつかうURL外形監視の手順がスクリーンショット付きで丁寧に説明されています。コラムでロードアベレージやcpuやdiskなどのシステムメトリックの意味か解説されていて、すばらしい!ノウハウたっぷりです。アラートを通知する運用では閾値を超えたときにアラートを発生して管理者に通知しますが、Mackerelでは、メールやSlackだけでなくLINEやYammerなども利用できます。これらの設定のしかたが説明されています。プラグインを作るmackerel-agentのプラグインを作る方法が解説されています。カスタムメトリックプラグイン/チェックプラグイン/メタデータプラグインが作成できます。シェルスクリプトでの例やGoでのヘルパーライブラリでの実装が紹介されています。丁寧な説明なので、Goを書いたことがなくてもすぐ理解できると思います。各種ツール連携と運用の効率化ここでは、MackerelAPIの紹介と、Fluentd/Chef/Capistrano/Serverspecとの連携について書かれています。ログを集約させたりChefで構成管理したりなどいろんなことができるんだなと初めて知りました。クラウド環境におけるMackerelここでは、MackerelをAzureおよびAWSで利用するための手順が解説されています。どちらも監視サービスを提供していますがお客さんによっては、同一のSaaSで監視したいという要件もあると思うので、チェックしておきたいと思いました。あと、Herokuの監視とDockerプラグインの説明もありました。最後の章で、落穂拾い的にGitHubとの連携やグラフの便利な書き方、セキュリティに関するノウハウなどが紹介されています。付録にMackerelの内部アーキテクチャが紹介されていて、面白いなぁと思いました。まとめとても良い本でした。わたしはゲームやマルチメディア系などいやゆるコンシューマ向けのシステムのことはよく知らないんですが、業務系システムでは「基幹システムのクラウド移行」「ハイブリットクラウド」「マルチクラウド」などなど、とにかくAzureとAWSが大盛況です。どちらも監視サービスを提供していますがお客さんによっては、同一のSaaSで監視したいという要件もあると思いますし、外形監視の要件もあるのでしっかり技術をチェック&ウォッチしておきたいと思いました。業務系システムにはミッションクリティカルなものも多く、サービス停止がビジネスだけでなく社会基盤に大きな損失を与えるケースが多々あります。ステークホルダーが多く、非機能要件も複雑怪奇なため「運用設計」が、ものすごくものすごく大事です。はてなのみなさんの極めて高い技術やノウハウを凝縮して煮詰めたMackerelは、国産SaaSということもありとても使いやすいので引き続き勉強していきたいと思いました。読みました!Tweet広告を非表示にする2018-03-07【書評】「Linuxのしくみ」を読みました!今はエンジニアではありませんが、いつかクラウドエンジニア/アーキテクトになりたい!わたしのひそかな目標でもあります。プラットフォーム技術を生業にするためには、ハードウエア/OS/ネットワークの深い知識は欠かせません。読ませていただきました。gihyo.jpわたしは、商用Unixしか基盤構築の実務経験が無く、Linuxは完全に独学でしかないため「プロ」ではなく完全に本書の対象読者です。そんな私ですが、大変勉強になりプラットフォーム技術に携わる多くの方におすすめしたいので書評をまとめました。前提読者この本の前提読者は「Linuxの使い方」ではなくタイトルの通り「Linuxのしくみ」つまり内部構造を理解したいエンジニアを対象にしています。第2版」の内容が頭に入っているとスムーズです。あと、Linuxのインストール/セットアップが自力でできる、基本的なコマンドは問題なく操作できるレベルのLinuxユーザであることが必要です。コンピュータシステムの概要OSとハードウエアの関係、OSの概要について説明があります。カーネルがハードウエアのリソース管理をどのように行っているのか、プロセスとはなにか、デバイスドライバとなにか、など基本的なことが沢山の図とともに説明されています。ユーザモードで実現する機能ここではシステムコールが「実験」をベースに説明されています。straceを介してPythonでHelloWorldしたときの挙動をみながら、write()システムコールが発行されてますよね!とか、親プロセスのプロセスIDを取得するコードを無限ループさせるとどうなるでしょう?などです。あと、ラッパー関数、標準Cライブラリなどなどの説明もあります。プロセス管理ここでは、fork()関数とexecve()関数についての解説があります。図を用いてプロセス生成の流れを説明し、親プロセス/子プロセスがメモリ空間にどう展開され、どう終了されるかが分かります。ここはややアセンブラの知識が必要になりますが、まったく知らない人も図をみてイメージできるので親切です。CASLIIぐらいの知識でぜんぜん大丈夫です。プロセススケジューラ40ページほどかけてプロセススケジューラの挙動を丁寧に解説されています。私もふくめて多くのLinuxユーザはカーネルがプロセススケジューラの機能を持っていて複数のプロセスを同時に動作させているのだなと理解していると思いますが、実際のところどのように「同時に動作させているようにみせかけている」かをたくさんの実験とともに解説されています。個人的には、、、nice()の挙動とかとてもわかりやすっ。Killerは何をやってくれる人なのかなどが解説されています。ここでも実験がたくさんあり、ページフォルトの実験やmalloc()、スワップの挙動などは難しく、私の頭脳ではちょっと別途改めて勉強が必要でしたが、、後半のCoWは「あ、、あああぁあぁあ、、、これは3年前のあのとき!あの本書いたときに読んでおきたかった、、、本!」という感じでとても分かりやすかったです。余談ですが、だいたい書籍では著者が書いたドラフト図を、初校でDTPのデザイナーの方が「いい感じ」に書いてくれるものなんですが、satさん本はすべての図が「殺風景」で、むしろこれはsatさん自らが「殺風景に書いてくれ!」とオーダーしないとできないレベルだと思われるので、いったい内部で何が起こっているのかが気になります。記憶階層ここでは、レジスタ/キャッシュ/メモリ/ストレージと記憶装置でどのようにデータが扱われているかが、ここでも「実験」をとおして見通せるようになっています。実際にファイルに書き出してどうなるかを追っていけるようになっています。ファイルシステムここでは、そもそもファイルシステムとはなんぞやから始まり、ジャーナリングのしくみ、コピーオンンライトでのファイル更新の様子などが、図をつかって説明されています。講義で黒板をみているような感じで、この上なく殺風景な図であるがゆえ、むしろシンプルに伝わる。ストレージデバイスHDDとSSDについてのしくみとデータの読み書きに関する実験が解説されています。エンジニアだった若いころ、某超エンタープライズ金融機関の基盤構築PJで一緒だった、Sunや富士通のエンジニアに教えてもらった(が、たいして頭に入っていない)のを思い出しました。スイングアームやプラッタの動きを居酒屋のお皿とお箸で早口のオタクが熱心に、、、そんな感じを煮詰めて本にした感じです。まとめとても良い本でした。タイトルや表紙が、明らかに自然派ママをターゲットとして意識している風なため、一見「本物のLinuxカーネルエンジニアたるものこうあるべき!」みたいなハードモードなものが綴られているのかなと思いましたが、中を開くとまったく異なるので正直驚きました。これはsatさんの頭の良さでもあると思いますが、さまざまな「実験」を通してカーネルの挙動と全体像を確認していくという、今までにない新感覚の目線でまとめられているので、論旨展開や情報の整理の仕方など読み物としても非常におもしろく、とてもインスパイアされました。読みました国内の大規模基幹システムもクラウド移行まったなしの2018年です。読ませていただきました。CAPTCHA大変勉強になり、多くの大規模基幹系業務システムに携わる方におすすめしたいので書評をまとめました。「企業」や「組織」でシステム開発・運用に従事し、AWSを活用したいアプリケーション開発者/インフラ技術者を対象にしています。大規模オンプレですでにBtoBの業務システムを開発・構築したことがある人向けでです。(間違う人はいないとは思いますが)ウェッブ系の方向け書籍ではないのでご注意を。AWSサービスの概要AWSの概要や主なサ―ビスが丁寧に説明されています。AWSのサービスはんぱないほど数があるのでここで俯瞰できます。全体設計(管理方針と移行計画)監査証跡についてやAWS導入にあたりネットワーク設計や運用処理方式などの考え方などがまとまっています。あと、オンプレからAWSへの移行についても説明があります。いわゆる概要方式設計に相当する内容です。アカウント管理と権限付与AWSを大規模システムで導入するとき、必ず必要な知識がIAMだと思うんですが、それがきちんと説明されています。OrganizationsのベストプラクティスやCogniteなども解説されています。AWSネットワークの構成要素で、通信要件をあげて物理構成/論理構成をまとめてます。設計項目として、アドレス設計/ルーティング設計/フィルタリング設計などが書かれています。システム設計とサービスの導入いわゆる、基盤方式設計(クラウドアーキテクチャ)がいくつか紹介されています。具体的にはオンプレミスとの連携を伴わないECサイトハイブリッド環境で運用する基幹システムWeb可用性向上パターンコンテンツキャッシュパターンDB可用性向上パターンジョブサーバパターンなど定番のものから、Redshiftをつかった大規模データ分析パターンなどのアーキテクチャも説明があります。あとは、CloudFormationのベストプラクティスなどもあります。大規模な業務システム移行に関するノウハウを持っているので、非常に非常に貴重な知見がたくさん埋まっているなぁと思いました。運用監視の設計・実施CloudWatchの説明や、CloudTrailを使った運用監視についてが解説されています。運用の章はまとめるのがすごく難しいのですが、、、とてもきれいに分かりやすくまとまっています。まとめとても良い本でした。情報が論理的に整理されていて粒度もばらつきがなく、読んでいて一切ストレスのない本でした。いつかこういう本が書けるようになりたい!と思いました。深層学習など高度な数理を必要とする技術に関する知識がエンジニアにも求められています。よいアウトプットを出すためには、必ず基礎知識として学んでおかなければいけないと思います。いう人は多いのではないでしょうか?本書は自分のペースで少しずつ自習ができる書籍で、私にとっては大変勉強になりましたので書評をまとめました。大学生のときに読みたかったわこれという感想です。www.shoeisha.co.jp前提読者この本の前提読者は、理系大学の教養課程で学ぶ数学を履修したことがある方向けです。ぶっちゃけセンター試験のような受験数学と、大学の教養課程で学ぶ数学は別物なので、文系の方には多少しんどいかもしれません。途中計算を端折らず、ごまかさず丁寧に展開しているのが、本書の大きな特徴(逆に、そういうたぐいの自学自習出来る書籍は、大学の教科書でもほとんどなさそう)なので、時間をかけてゆっくり読み進められると良いかなと思います。集合と写像や、実数とは、、という基本的な内容ですが、1-2で実数の完備性について詳しい説明があります。わたしはこの実数の完備性について、この本で初めて知ったのですが、、、、これは、後述する関数の連続性を考えるときの基本的な考え方になります。逆関数など基本的な計算の仕方が丁寧に説明されています。文章での説明だけ読めば十分に理解できますが、具体的な関数を挙げてグラフによる例が説明されています。2-2では、関数の極限でヘビサイド関数の説明や、関数の連続性に関する丁寧な説明があります。は?!?」という深淵をみてしまい、あとは完全にアレです。関数の微積分ここでは、関数の微分積分について取り上げられています。微分係数とはなんぞや、導関数とはなんぞや、という高校数学ぐらいからのレベルで易しい説明があります。具体的に計算例をあげて、かなり具体的に導関数の計算方法を説明されているので、文系の方で「わ、、、わからん、、、」となってしまった方は1章2章はいったん読み飛ばして3章と4章から始めて、理解できたところで1章2章に戻ればいいと思います。積分に関しても、まずは区分求積法で近似する手順を順を追って説明されています。わたしだったら絶対に「部分積分の公式です、覚えましょう(キリ」と言ってしまいそうなところです。しつこくきっちりかっちり数式を追いながら説明されています。機械学習でよくさらっと登場するネイピア数ですが、そもそもこれの正体はなにものなのか、、が熱く語られています。三角関数も、高校数学レベルから説明がされています。内心「(基礎のキなので)加法定理や余弦定理はさすがに説明要らないんじゃ、、、、、」と思いましたが、きちんと図を書いて証明されています。関数の近似で使われるテイラー展開についての説明があります。テイラー展開も、機械学習でナチュラルに多発するキーワードだと思うんですが、ここでも数式を使いながら厳密に証明がされています。私は、本書を読むまで無限小解析がよく分からず、「0に近づく速度??と、、は?」という状態だったのですが、ここの説明でだいぶイメージできるようになりました。これは大学のときに読みたかったなと思いました。数値解析では高階偏導関数がばんばん出てきます。その数式の意味するところをきちんと理解しておかなければ、機械学習や数値解析で、一見それっぽいモデルを作ったりシミュレーションしたりの実装はできたとしても、モデルや解析結果の妥当性を1bitたりとも議論できなくて、ぐぬぬぬぬとなるはずです。ここでは、全微分と偏微分は何が違うのか、、、から始まりテイラーの公式を使って近似する説明がされています。数式が複雑で、難しそうに見えますが、力業で計算するだけなので、5章までの内容さえ理解しておけばそんなに難しくないのではないでしょうか。まとめとても丁寧な良い本なので、長く広く読まれる本になるといいなとおもいます。「機械学習のための数学」というのはたぶん無くて、基礎にあるのは一般的な「線形代数」だったり「統計」だったり「微分積分(解析学)」だったりするかなと思います。これらをきちんと学ぶほかなし。簡単な最小二乗法やニューラルネットワークのようなものを例題にあげて、そこに出てくる数式の意味や解き方をイラストで図解して書いてしまうと思います。商用誌の世界では、ある程度の部数を売らないといけません。そのため、表面的な内容をさらって読者に手を動かしながら理解してもらえる本は、安牌なのです。残念ながら、そのたぐいの本を読んだだけでは「最小二乗法」と「ニューラルネットワーク」しか分からないのです。数学はそういうものじゃない!!あらためて、中井さんすごいよなぁ。仕事も大掃除も終わってないですが、2017年が終わろうとしています。2017年、良い1年でした!2017年のアウトプット8月/9月の2か月はブラブラしていたので、実質10か月でのアウトプットです。毎月なにか書く、2か月毎になにか発表ぐらいのペースでした。2017年新しくチャレンジしたこと2016年はDockerコンテナだけだったのですが、上方向と横方向にちょびっと触手をのばしました。1年間地味に解析学と線形代数のごく簡単なのを勉強して、OpenFOAMでカタコトの実装ができるようになったのは、わたしのなかではとても大きいデス。チュートリアルをもとに非粘性流体の解析をし、ParaViewも使い方を何となくマスターし、CFD関連の論文も少しだけ読みました。来年はきちんとどこかでシミュレーションの発表できるようにしたいなと。機械学習の基本も勉強しました。書籍を読んだりオンラインセミナーを受講したりでサンプルやチュートリアルなどをやりました。TensorFlow/Kerasでごく基本的な画像推論や転移学習などができるように。CNNは何となく理解です。データ集めて前処理して学習モデルを作るだけじゃなく、学習基盤と推論アプリをデプロイしてサービス提供もきちんとやりました。オンプレPCクラスタやクラウドのVMで学習し、KubernetesクラスタでWebアプリとして公開したり、推論APIをAndroidからコールするなども。あと、AndoridThings/RaspberryPiなどデバイス側でTensorFlowを動かし推論するなどもやりました。TensorFlowLiteは今後もひそかに注目したいです。Batch方面は楽しく勉強できました。現時点の予定ですが、、、プラットフォームに関する書籍を新たに書かせていただく予定です。あと今年ちまちま書いた本が4月に刊行になります。2017年は同人誌を書いたのがとても楽しかったです。自分が好きなものを好きなようにつくる、という行為そのものが好きなので、手芸とか工作とかそういう感じで。2018年もプライベートで没入できるなにかができればいいなと。体が丈夫でないというのもあり、2018年はいつくたばっても後悔のないように「やりたい!」とおもったことはすぐやろうと思ってます。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。