元々なんでも屋ってたけど、我が部署名もSREになったし、インフラエンジニアって書くと『IT』警察が寄ってくるからSREでいきましょう。短いのはイィ。 SREがやることは書籍『O’Reilly Japan – サイトリライアビリティワークブック』がほぼ語っていますが、もうちょっと噛み砕いて自分的にはこの四大行を軸に活動すれば、いっぱしのSREになれんじゃねっていう戯れであります。 SREのお仕事を大雑把に表現すると、サービス開発者が作成したアプリケーションを、動かす環境を用意し、安全・効率的に動かし続けることだと思っています。 IT業界の事情変化につれて、SREの重要性は高まる傾向にあり、それに伴いSREとして活動を希望する人材も増えたような、そうでもないような。気がするけど、SREとして食ってく気ならこれら四大行が基本であり奥義になるよって話です。 『構築』 アプリケーションを動かすための

ECS Fargate でコンテナ内部をいじくってたら、いくつかやりたいことがあって、まとまりができたので更新です。 メタデータの扱いがわかれば大体イケるみたいな感じですが、たどり着くまでわりと時間かかったので、サクッとまとめ。 Fargate に渡される環境変数 最終的にはコンテナに sshd とか用意しないのがベターではあるのですが、やっぱりSSHは大正義。シェルで作業しないと、こーゆーのは捗りません。 Fargate で基本的な値が入った環境変数はこのように取得できるので確認します。これがあれば、あとはトントン拍子に進みますね。 (参考) Amazon ECS で “アクセス拒否” エラーを発生させないように IAM タスクロールを設定する $ sudo strings /proc/1/environ | sort AWS_CONTAINER_CREDENTIALS_RELATIVE

あけおめなので、ジャブから入ります。左を制するものは世界を制すです。 EC2 のインスタンス・リソース制限が、起動数からvCPU数に変わって結構経つのですが、その監視を気分転換に追加しようと思って放置しておいたアレというか、新年ブーストのためにワザととっておいた、そんなアレです。 参考ページ Amazon EC2 で vCPU ベースのオンデマンドインスタンス制限が利用可能になりました | Amazon Web Services ブログ よくある質問 > EC2 オンデマンドインスタンス制限 – Amazon EC2 | AWS AWS Limit Monitor が vCPU ベースのオンデマンドインスタンス制限モニタリングのサポートを開始 EC2 の起動制限がサーバー台数から vCPU での制限へ変更されます – サーバーワークスエンジニアブログ vCPUの上限をチェックするLambd

EKS Fargate が出たので、男の子なら ECS Fargate と対決させてみたくなるじゃないですか。 でも、結果が全然おもしろくなかったので、雑にいきますね！ EKS のCPUモデル まずは、EKS Fargate を起動して、CPUをチェックしていきました。リソース量を多くしてあからさまに変わったら恥ずかしいので、ちゃんと１回ずつ網羅しておきました。例によって、テーブルに起こすの面倒なので画像で失礼しやす。 ちな、CPUの性能値については、私の大好きなこちらから検索したものになります。 CPU Benchmarks いくつか補足を。 起動の時間にはムラがある。おそらくNodeとして新規起動なのか、起動済みに入るのかで変わるのだろう CPUモデルはリソース量に関係なくランダムだと思われる PodからみたNodeのメモリ容量は、4GiB弱～32GiB あたりで構成されるようだ 30

ずっとKubernetesについて書いてきましたが、ここらへんでコンテナのリソース…… つまりアプリケーション・サーバーとしてのリソースの試算について考えてみます。別にコンテナじゃなくてインスタンスでも考え方は同じなので、タイトルからEKSとか抜いてシンプル回帰しております。 ぶっちゃけ、リソースの試算と一口に言っても、実際には色んな要素が入り混じって変化するので、色んな考え方があると思います。なので最初に明記しておくと、今回は特定の項目に着目し、面白半分、もう半分は真面目に計算したコンテンツという感じでよーそろーです。 はじめに なぜこんな試算をする気になったかというと、コンテナの設定をする上で、１インスタンス（Node）あたりのリソースがこれくらいなら、１コンテナあたりにどのくらいのリソースを割り当てて、コンテナ内部のアプリケーション用プロセスは１プロセスあたり何メモリだったら、何接続

前回、Podの割り当てリソース量が小さいほど、急増する負荷や、Nodeのスケールアウト時に弱いのでは疑惑が上昇しました。 その対策として、メモリのLimitを外すことはアリなのかどうか。メモリの NoLimit はそもそもどういう挙動なのか、を知っておくために行った攻めの検証となります。 概要というか検証前の頭ン中 PodのメモリもCPUみたいに NoLimit で動かすなんて、無理っていうか非人道的っていうか、絶対死しか待っていないでしょって思い込むのは良くない！と思い直すことにした。 Pod で動かすWEB・APP系のデーモンの機能次第ではあるんだけど、もしメモリを allocatable いっぱいまで使ったり、落ち着いたら複数のPodでの使用メモリ量が平均化したり、をできるならば、小さいPod君でも一時的にイキれることで弱点を克服できるかもしれない、と思ったのだ。 多分、ていうかほぼ

前回の続きで、今回はPod数が多い場合のメリットを考えていきます。 ぶっちゃけ、こういうところまで考え込まずに運用しちゃうほうが、幸せだと思います。私は、古いゲーマーなので、穴や弱点を探すのがすきだからやってみている、そういう感じなのです。 Nodeリソースの有効活用 (少) ☓ <---> ○ (多) Node にてサービス用Pod に割り当て可能なリソースは、Nodeで必要な量を引いた allocatable な CPU や Memory、そしてそこから基盤用Podリソースを差し引くことで確認できます。(参考) Node Memory が 4096 MiB だとすると、allocatable Memory が 4000 MiB などに減る。そこに 1000 MiB の Pod を起動しようとしたら、ちょうど 4Pod 起動できることになるけど、allocatable Memory が

前回の続きで、『NodeとPodのリソース量と、NodeあたりのPod数はどのくらいで運用するのが正着なの？』の答えを求めて幾星霜。 正解とは言わないまでも、有効と言える考え方まではもっていきたい。少しずつ寄せていって、詰めきれるかは閃き次第。そんなノリで Let’s & go. 概要 NodeあたりのPod数ってなんぞや？ってところからいくと、WEBサーバーのような同内容の複数Podであることを前提として、1Nodeの中で起動できる最大Pod数のことです。これは、Resource Requests を調整することで決定できます。 Node 8vCPU 32GiB にて、Pod Requests 8000m 32GiB だと最大1Pod だし、2000m 8GiB だと最大4Pod になる、というおさらいです（面倒なので端数はなし）。 選択肢としては、1～16Pod くらいまであるとして、

コンテナは便利イコール運用も簡単。とはならず、むしろ仕組みの理解や設定調整は、旧来のシステム構成よりもしっかり取り組まなければいけないイメージがよろしいかと思います。 適当に運用がうまくいくのは小規模までで、それ以降はおそらく偶然上手くいってるだけか、突然の死を向かえるかの二択になる気がしています。特に今回のリソース周りは旧来のシステムとはけっこう感覚が異なるので、脳みそのアップデートが必要なくらい大事な部分だと感じています。 Resource の requests / limits と CPU / Memory リンク集 この辺はちゃんと読んでおいたほうがよいです。 Managing Compute Resources for Containers – Kubernetes KubernetesのResource RequestsとResource Limitsについて – Qiita

わかっちゃいたけど後回しにしていた Lambda Python2、たまたまやる気が燃え上がったので Python3 に移行しました。 Python 自体はまぁそこそこの素人なので、詳しいことはあんま書かないで、やったこととか変更点のピックアップとかしていきたいと思います。 Python2 よや すら かに Python2 がこんな感じで終焉を迎えるので、 Python 2系終了のタイムリミット迫る。早く「3系」に切り替えよう：気になるニュース＆ネット記事 – ＠IT Lambdaの公式説明的には、段階的ではあるものの、End of life 以降は使えなくなっていくので、それまでに切り替えようねということになります。 ランタイムサポートポリシー – AWS Lambda Pythonの公式をチェックすると、Python2.7 は 2020-01-01 なので、もーさすがに頃合いというか早よ

地味に便利な DaemonSet というのがありまして、1Node に 1Pod 起動する仕組みになっています。 これを使って、Node単位でやりたい処理を仕込むことができます。例えば……恒例のスポットインスタンスの強制Terminate対策とか、してみましょうそうしましょう。 DaemonSetとは 一応、説明は軽く見たほうがよいのですが、 DaemonSet – Kubernetes Nodeの起動後に確実に1pod起動されるということで、EKSの場合は aws-node という名前のPodが起動します。が、こいつに関する詳しい公式説明が見つからないのが、ちょっと残念なところ。 $ kubectl get pod --all-namespaces | grep aws-node kube-system aws-node-2fz7g 1/1 Running 0 40m kube-syst

前回の続きで、環境変数を取り扱う時のセキュリティについて考察していきます。 あくまで考察であって、正解ではないです。セキュリティなんてものは環境によって必要な内容が変わるので、こんな風に考えて、こんな感じが正着の１つちゃうん・・・くらいなテイストでお願いしますだ。 はじめに 環境変数を扱うにあたって、セキュリティについて考える必要があるわけですが、そもそも本当に考える必要があるのか？どこまでやれば十分なのか？はサービスによって異なるので、ある程度の条件を想定して考察していきます。 似たような考察はこちらでもされているので、ぜひ。 なぜ､Kubernetesを使う際にSecretを暗号化するのか？ ｜ DevelopersIO 最も環境変数の利用としてありがちなのは、アプリケーション・サーバーがデータベースへ接続するための、接続先・ユーザー・パスワード といった情報でしょう。その中で特に、パ

コンテナはどんな環境でも同じように動くよ！ってのがウリの１つではあるのですが、そのためには環境ごとに異なる指定値はコンテナ外でKey/Valueを設定し、Pod の環境変数として扱えるようにしてあげる必要があります。 ここでは、色んな環境変数の扱い方があるということを整理するところまでやって、取り扱い方の考察については次回に続きたいと思います。 マニフェストによる設定 ここでは Deployment を使った、環境変数の定義方法についてまとめていきます。 env ここで書いた env の name, value がそのまま環境変数になる火の玉ストレートです。下記では ENV=production のようなヤツが設定されています。 resource "kubernetes_deployment" "main" { ... spec { ... template { ... spec { ..

みんな大好き Autoscaling の時間です☆ 少し長めになっちゃったのですが、分割するとわかりづらくなりそうだったので1つでぶっ込んでいきます。 さてここで新たに、helm という仕組みが登場します。Kuberntes におけるパッケージ管理みたいなもので、これも Terraform でやっつけちゃうので安心して・・・うーん、最後までいければいいですね！くらいな感じです。 EKS における Autoscaling の仕組み まずおさらいとして、ALB + EC2 の時はどうやっていたかというと、Autoscaling Group に CloudWatchAlarm を組み合わせて、例えばCPU使用率を条件に、何％を超えたら既存台数の何％を増加、何％より低くなったら既存台数の何％を減少、のように実現していました。 これがガラリと変わって CloudWatchAlarm とオサラバします

前回でPodも起動できたことだし、ここらでややこしくも重要なPodの配置管理についてやってしまいます。 細かい説明は他サイトにお任せリンクにして、ここでは例えばどういう意図で配置を考えるのか、Terraformで管理するとどういうコードになるのか、というのを確認できればと思います。 Pod配置を管理する意図と手段 意図 Pod配置とは何のことかというと、PodをどのNode もしくは、どのNodeの集合体に起動するかを、任意で決めるということです。配置することを、スケジュールとも呼んでいるようですね。 なぜ、あるPodが載るNodeを選ぶことがあるかというと、まずNode自体には色んな条件があります。インスタンスタイプ、AZ、オンデマンド／スポット、Autoscalingする／しない、などなど。そしてPodにも色んな特性があります。複数Podのうち一部が落ちても大丈夫だったり、管理系のでき

とうとうこの時がやってきました Pod 起動、からのHTTPリクエスト流すまでのヤツ！ 先に書いておきますけど、この構成はあくまで色んな手法がある中での一例です。１つしか知らずに突っ走るのではなく、いくつかつまみ食いしてから、やっぱコレやなって決めるくらいがほどよい、お年頃なシステムなのです。 Deployment Pod はもちろん単体で起動して遊ぶこともあるでしょうが、ここではWEBサービス用途なので、同じコンテナを複数起動して耐障害性と負荷分散を目的としていきます。 Pod を起動するためのリソースは複数あって、特に古めの記事を見ちゃうと Replication Controller というのが目に入ることがあります。が、ここでは有無を言わさず Deployment を採用していきます。理由は新しいからの火の玉ストレートです。もし、違いとか知りたければこの辺を見ておくとよいでしょう。

ようやく前回でNodeを起動できるようにしたし、やっとPodを起動してｷｬｯﾊｳﾌﾌできるぜって、そうは問屋が卸さねぇ！ Terraform が Kubernetes を管理できるようにして、さらにちょっとした塩コショウで味付けて、今回は終了です。焦らせば焦らすほどPodの味に深みが増すとか増さないとか。 Kubernetes Provider まずは作成した EKS Cluster の情報をチュウチュウします。 data "aws_eks_cluster_auth" "main" { count = local.on_eks ? 1 : 0 name = local.eks_cluster_name depends_on = [aws_eks_cluster.main] }

※この辺から訂正と追記しました(10/8) 前回でKubernetesへのアクセスができるようになりましたが、ここで一歩引いて EC2 Node を起動するための Autoscaling Group を作成します。 LaunchTemplates と Autoscaling Group だけじゃ味気ないので、UserData でこんなことやってますってのを濃いめに解説するところまで、いきたいと思います。 Launch Template LaunchConfiguration はもう使わないので、LaunchTemplateにお世話になります。 UserDataのシェルスクリプトについては、最後に記載と説明をします。 ここのチョットしたポイントとしては、template_file において template = file(“script.sh”) と vars を使わず、templatefi

ブログネタ飽和病により更新が停滞しているので、時事ネタで軽くリハビリです。ある意味、ネタ不足の時より書けない気がする・・・ 2019/09/24 にCentOS 8.0がリリースされたので、開発環境用にインストールと、いつもやるようなベースシステムの構築をやってみたのでメモメモです。 リンク集 サッと見ただけですが CentOS-8 (1905) リリースノート CentOS 8 と CentOS 7 の違い、yum やミドルウェアにも要注意 – サーバー構築と設定 ～初心者にも分かりやすく解説～ CentOS Linux 8 | Step by Step Installing CentOS Linux 8 with Screenshots OSインストール 私の場合、適当なLinux環境で、インストールイメージから QEMU + KVM で起動して、VNC でグラフィカルなインスコ画面を

それでは、ようやく Kubernetes on EKS を構築していこうと思います。一気に進めるとグチャグチャになりそうなので、こまめに分けていくよう意識していきます。 今回は、Kubernetes のクラスタを触れるようにするとこまでで、実際には何も動かないですが大事なベースです。 概要 Kubernetes on EKS を Terraform 一本勝負でゴリゴリ書いていきます。EKS も Kubernetes も Helm も全部です。あとは LaunchTemplate の user data などのいくつかのちょっとした処理でシェルスクリプトを使う程度です。 Terraform のバージョンは v0.12.0 以降を想定しており、自分の環境だと terraform も provider も常に最新にしていくよう意識しています。特に kubernetes provider は発展途