大好きなLambdaでArm64 Graviton2 CPUを利用できるようになったので、既存のPython3.6 + x86_64 から切り替えてみました。 基本的でたいした内容ではないですが、ギリ時事ネタということで、要点をまとめてみたいと思います。 更新内容 とりあえずLambdaの更新内容の確認から。 AWS Graviton2 プロセッサを搭載した AWS Lambda 関数 – Arm で関数を実行し、最大 34% 優れた料金パフォーマンスを実現 | Amazon Web Services ブログ AWS Lambdaがarm64アーキテクチャをサポートしました | DevelopersIO これからLambda + Pythonで構成する場合 CPUアーキテクチャが増えただけでなく、Pythonも１～２年でマイナーバージョンが増えていくので、選択に迷うことがあるかもしれません

データベースには処理の一貫性を保つためのトランザクションという仕組みがあり、扱うデータ箇所がカチ合う場合に、後発のクエリが待機状態になることがあります。 その待機がどのくらい発生しているかは、DBのステータス値やメトリクスから判断できるのですが、ではどのようなクエリで発生しているかとなると、調べるのが面倒くさい。というところから発生したPythonスクリプトになります。 LockWaitを調べる理由 そもそも私の業界のWEBアプリケーションの場合、クエリがロック解除待ちを長時間することはほぼありません。スロークエリを撲滅させるのと同じで、１クエリに0.5秒以上とか必要としちゃうと、ユーザーへのレスポンスとしては容易に１秒以上になって、ユーザー離れの要因になるため許容できないからです。 しかし複数のサービスを観察していると、LockWaitの発生頻度が結構違ったりして、それはまぁアプリケーシ

久々に溜まったブログネタ放出をしようかなと、その前に下書きから掘り起こしてきた、いまさらなスロークエリ関連で準備運動です。 RDSのスロークエリ情報は当然、集計を自動化していつでも見れるようにしてあるのですが、ちょいと必要があったので、今回はあえて単発ログを集計する形に切り出したものを用意してみました。 スロークエリログの必要性 最近はNewRelicとかで、アプリケーションの処理を分別して処理時間などを集計するので、それで課題となるクエリを確認したりもします。 非常に便利な仕組みですが、アプリケーション外のジョブなどが実行したクエリは集計されないことや、負荷試験で課題を炙り出すときだとテスト環境にエージェントやライブラリを仕込む必要がある、といったデメリットとまでは言わないまでも面倒さがあります。 その点、スロークエリはサーバー側で記録するものなので、0.1秒とかでONにしておけば、対象

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

三年以上前に サービス品質の改善効率を高める仕組み | 外道父の匠 の一部にて、GeneralLog と EXPLAIN を使って、クエリ品質を自動算出していることを書きました。 この仕組みは2011年に開発して以降、言語変更や新環境に適応させたりしつつも、ほぼそのまま稼働し続けていて、最近はRDSが対象になることが多いのですが、RDSだとGeneralLogの採取に問題が発生したので、DBサーバーではなく、ClientでのPythonを使った採取に切り替えてみました、という話になります。 RDSのGeneralLogは高QPSでは非推奨 RDSで GeneralLog を採取するには、パラメータグループで general_log を ON にするしかないのですが、数百qps 程度なら問題なく動いても、数千～万qps となると、ほぼ期待通りに切り替わってくれなくなります。 それまでは、AP

Lambda Pythonが楽しい季節になって参りました。 クラスを書いていると変わった挙動に出会ったので、軽く調べてメモしておきます。 クラス変数の挙動試験 キッカケ 最初は、Pythonにおけるクラス変数とインスタンス変数の関係的なものを知らず、変数の初期化の役割をクラス変数にやらせていました。 それが、どうもLambdaで実行するとクラス変数の値の変更がキャッシュされてしまうことがあるようで、そうでないこともあるようで、色々と不審に思って調べ始めました。 テストコード 内容はこんな感じ。 複数種類のクラス変数を定義 ホスト名を確認 現在のクラス変数値とメモリアドレスを確認 クラス変数を更新 これを何度も実行する import os import time from socket import gethostname def lambda_handler(event, context)

Lambda Pythonの最後三つ目の記事で、今度はCollectdに値を送信する内容になります。最後にちょろっと要望／感想的なことを書いてます。 普段は管理サーバーにて、CollectdのExecスクリプトでAWSのAPIを叩いてPUTVALを送っているのですが、これもサーバーレスにできるなと。ただ、見て分かる通り、Zabbixよりだいぶ面倒くさかったです。 使い方 Collectdプロトコルについてはこの辺で。 Binary protocol – collectd Wiki Python collectd package v1.0, collectd module source code :: PyDoc.net Lambdaに以下の様な構成でzipをアップロードします。 __init__.py は空ファイルです。 . ├── GraphMetricSender.py └── mod

Lambda Pythonの二つ目の記事で、今度はZabbixに値を送信する内容になります。 普段はZabbix Agentを使っていたのですが、それだと Server => Agent:10050 への通信が発生してしまうので、それに無理に対応するのはウマくないと判断し、Zabbix Senderと同じ手法をとりました。 使い方 Zabbix プロトコルのドキュメントはこの辺で。 3 Passive and active agent checks [Zabbix Documentation 2.4] Docs/protocols/zabbix agent/2.4 – Zabbix.org Docs/protocols/zabbix sender/2.0 – Zabbix.org Lambdaに以下の様な構成でzipをアップロードします。 __init__.py は空ファイルです。 . ├

AWS Lambdaが年内にVPC対応するとかしないとかを受けて、管理系の監視データをサーバーレスにしようかなということで、いくつかスクリプトを書いてみました。 一緒くたにすると見づらいだけなので、この一つ目の記事ではZabbix APIを叩くクラスを貼り付けておきます。また、要望／感想の類は、関連記事の最後の最後で書こうと思います。 ご注意 私はPythonを真面目に書くのはこれが初めてなので、基本ができていなかったり、慣習を知らないまま書いている部分があるかもしれません。 なので、全体の構成とかよりは肝心の処理部分やプロトコルだけでも参考にしてもらえればな、という気持ちで共有しております。 使い方 Zabbix APIのドキュメントはこの辺で。 17. API [Zabbix Documentation 2.4] Lambdaに以下の様な構成でzipをアップロードします。 __init