監視するMackerel特定のホストの紐付かないメトリックをMackerelのプラグイン経由で監視する場合、AWSであればEC2上に監視専用のホスト(いわゆるmonitoringホスト)を立てることが多いです。これは便利な一方で、以下のような問題点があります。EC2ホストの面倒を見ないといけない趣味で使う用途だとEC2のホスト台を毎月あまり払わずに済むとうれしい特に一番最初の面倒を見るコストが一番大きいわけですが、サーバーレス/コンテナ時代なので、いいソリューションがあればそれに乗りたいわけです。Lambdaで試されている方がおられます。Fargate上でやっているのですが、せっかくなのでどんな感じでやっているか簡単に書いておきます。mkrおよびプラグインが入ったdockerイメージを作るmkrやMackerelプラグインを入れるDockerfileを書きます。/app/monitorFargate上で実行するshellスクリプトを用意プラグインを実行して、その出力をmkrを使ってMackerelにメトリックとして投稿します。サービスメトリックとして投稿しても、ホストメトリックとして投稿してもよいと思います。${MACKEREL_HOST_ID}まだ存在しないmonitoringホストを指定したい場合、API経由で新規ホストとして登録するとよいでしょう。以上をbuildして、ECRにイメージを登録します。タスクを定期的に実行する先ほど書いたshellスクリプトを対象にしたタスクを定期的に走らせます。私の場合はCloudwatchイベントで定期的に走らせています(趣味のものなので、例えば1時間に1回とかの頻度で特に困らない。対応できないことも多いので...)。そもそも論としてMackerel公式のAWS/Azureインテグレーションが充実すれば、ユーザーがこういったmonitoringホストを立てる工夫をする必要がなくなるという話があって、それはその通りだと思います(著者はMackerelの開発者の一人です)。インテグレーションも最近どんどん増やしていっていますが、インテグレーションで対応しきれないすごくニッチなメトリックを取りたいというケースは今後もmonitoringホスト相当のものが必要なケースはあると思います。Lambdaや今回紹介したようなFargateを使った方法を試してもらえるといいかもしれません。監視するもっと読むコメントを書く2019-01-092018年の砂場活動振り返りインフラインフラやミドルウェアにとにかく苦手意識があるが、仕事的にいつまでもそう言ってられない。そこで、最悪全部ぶっ壊れても大丈夫な砂場を作り、そこを土台に活動をするというのを2018年の目標に設定していた。結構な時間をかけたこともあり、それなりの砂場と活動ができて、自分としても勉強になってよかった点が多かったので振り返りを書きます。一個一個ちゃんとエントリ書いていたので、振り返りが楽で助かった。Newsだけど、2018年1月時点ではそもそもWebアプリですらなくCLIアプリだったデータの管理もデータベースではなくテキストファイルという素朴な作りだった。最初はCLIアプリをWebアプリにする活動をやったが、その後はAWS上にインフラ部分の構築を進めた。次に一台のEC2をAWSコンソールから立てて、sshでログインしてyumコマンドを打って...という10年前くらいのサーバー構築をやった。EC2のスペックを変えて作り直すのはあまりにもダルかったので、ansibleでミドルウェアのインストールや必要な設定をやらせるように。一台のEC2にWebアプリもredisもpostgresも同居してという状況だと辛い状況(公開する関係でWebアプリはpublicサブネットに置きたいけど、DBもpublicサブネットに置いてる...)になるのは目に見えていたので、managedサービスが存在するものはそれを使うようにした。AWS上でのリソース構築は会社でCloudFormationを使うことが多かったので、自分も使うことにした。CloudFormationはまあ書くだけという感じだけど、VPCやサブネット、セキュリティグループをどう設定するとよいかをイチから自分で考えるのは普通に勉強になったので、やってよかったですね。CloudFormationのテンプレートはどういう粒度で分割すればいいのかは未だに分からない。CloudFormationのyamlを編集するのも辛くなってきたのでaws-cdkも試しましたが、こちらはまだまだ開発中という感じだったのでしばらく放置しています。WebアプリをEC2上に立てていたが、世の中コンテナ化が進んできていてどういうよいところ悪いところがあるのか知りたい自分も知りたい、仕事的にも知っておく必要があるということでコンテナ化を進めた。最初は自分でEC2を立ててECSのクラスタにjoinさせる、という形を取っていたが「いい加減EC2の管理をしたくないなぁ...」と思ってきたため、途中からFargateを使うように。FargateだとEC2を立てておかなくてもdesired-countを変えればアプリケーションサーバーの個数も変えられるので楽になった一方、EC2より若干お高いとかログ周りが微妙(fluentdとの連携とか)、Fargateの起動は若干もたつくなどが試して分かってきました。この辺から必要なリソースをある程度自由に変更できるようになってきたため、砂場感が出てきました。Batchも使えるようになりました。Batchに投げ込むことができるようになったため、バッチが走っている間レイテンシーが落ちる...といったことを心配しなくてよくなりました。Batchは仕事でも使っていますが、便利ですね。Batchで複数のジョブを管理していると、そのバッチの順序依存関係をcron職人芸ではなくもっと賢い方法で管理したくなりました。Functionsが便利そうだったので導入したのもこの頃でした。試した内容はLTで発表も行ないました。LogsからKinesisを通してS3にログを転送して、Athenaで分析するといったこともやりました。やってみたのはよかったですが、ログの流量がまだまだ少ないのでどういうところで困るかはまだまだ見えてこないという状況ではありました...。ミドルウェア編インフラ編である程度下周りは整備したので、パフォーマンス改善の活動を通してミドルウェアのことを知る活動も行ないました。ISUCON勢には当たり前すぎるところから、という感じではあります。当たり前のことを当たり前にできるようになっていきたい。チューニングをした結果、改善したのかそうでないのかを判断するためのモニタリングをやれるようにしたり、DBで必要なインデックスを張るとか、コネクションプールを適切に設定するとか、そもそもボトルネックきちんと把握できてる??といったことを少しずつやっていきました。AWSの課金額が順調に増えてきてしまったのもこの辺だ😇チューニングではないけれど、Nginxの設定をあれこれいじったりということもやっていました。砂場活動のメインの目的はインフラ方面の知識および経験の強化ですが、Webアプリを作る過程でフロントエンドでも勉強になりました。Vue.jsを導入してSPAにしたり、Cognitoを使って認証させたりといったことをやっていました。以前は趣味でjavascriptを書く機会が皆無だったので、趣味でもjavascriptを書く機会ができたのはよかったなと思います。当初は特に予定がなかったサーバーサイドレンダリングも導入成功していた。まとめ2018年の砂場活動を振り返りました。よい設計に落し込むまでめちゃくちゃ遠周りしているし、AWSへの月々の課金も無視はできない金額になっています(現実的なところに落と込んだら課金も減りつつある)。以下のような大きなメリットがありました。遠回りするとどのアプローチがどうダメだったかが身を持って分かる多少痛い目に合わないとどれくらい困るかがイメージが湧かない性格...多少データがぶっ飛ぼうが困るのは自分だけなので、思い切ってあれこれ試せる精神的な障壁を低くするという砂場活動の目的を十分果たせていたと思いますインフラ/ミドルウェアの苦手意識はまだまだ払拭できてはいませんが、2018年に作った砂場を足場に2019年には多少の武器にしていけるようにしていきたいなと思います。id:shiba_yu36さんの力が大きかったなぁと思います。Vue.jsタイトルの通りやりましたというお話です。以前は$http_user_agentを見て、googlebotだったらrendertronを経由させてレンダリングした結果を見せることでお茶を濁して凌いでいた。この方法、SPA自体は全く変更する必要なくbotにレンダリングされた結果を見せることができるというメリットがある一方で、以下のようなデメリットもあること分かってきた(分かってはいたものもある)。rendertronが結果を返すまでに3-4秒程度かかるrendertron自体に手は入れたくないため、お手軽な改善方法がないbotにならある程度レイテンシーかかっても問題ないという話はありそうrendertronがそこそこメモリを食うめちゃくちゃ食うというわけでもないが、メインのAPIサーバーよりメモリを食っていて何だかな感がある人間とbotにhtmlを出し分けている描画されるものが決定的に異なるわけではないが、若干気持ち悪い両方のテストが必要になるrendertronで対応するのはそもそも邪道だなとは思っていたので、Nuxt.jsで真面目にサーバーサイドレンダリングを行なうようにした。Requestは以下。GitHubpackage-lock.jsonを入れていなかったのでdiffがやたら大きいですが、本質的にはhtmlテンプレートファイルの置き場所が変わったくらいです。元々はVue.jsを使ったSPAだったので、そこまで大きな変更点はないです。覚えている範囲でNuxt.js用に変えた点としては以下の通り。テンプレートファイルの置き場所変更Nuxt.jsはlayoutやpages、componentsなどある程度ディレクトリに関して規約があるため、それに従うようにします特に整理できていなかったので見通しはよくなったroutingも基本的にpagesのディレクトリに従う形クライアントサイドでデータ取得している箇所をサーバーサイドで取得するようにメインの変更点。asyncDataを使うようにするVue.jsのときはrouterに必要な情報が入っていたが、Nuxt.jsではcontextに必要な情報が入っている。context.route.params.MyParamという感じ。慣れは必要だけど、めっちゃ大変という感じではない。Vue.jsをある程度触ったことがあれば大丈夫。初回のhtmlはサーバーサイドで生成して、それ以降の画面遷移はSPAのときと同じような感じで動くので、SPAで書いていたものもほとんど無駄にはならなかった。rendertronはなくせたものの、サーバーサイドでレンダリングするNode.jsは相変わらず必要。ECSで動かしているので、専用のDockerfileを用意する。いっても必要なファイルをコピーする、くらいしかやっていない。ECSのタスク定義にもよしなに修正を入れる。["npm","run-script","start"]静的ファイル(今回の場合はjsしかないけど)はnginxで配信させるようにしたかったので、nginxも適当に書き換える。}}docker-componentsを頑張って書いて手元でNode.js/APIサーバー/Nginxがそれぞれ連携して動いているかを確かめられるようにすべきと思いつつ、面倒くさくなって本番に導入しながら確認した。導入後の所感Nuxt.jsなかなかよい、規約などに従ったほうがカオスにならないのでサーバーサードレンダリングせずにSPAするだけでも導入して損はあまりなさそう人間とbotに出し分けしなくてよくなったので、見ないといけないポイントが減ったrendertronと比較してレイテンシーは改善された(そりゃそうだ)とはいえ、短時間にアクセスが集中すると200を返せなくなるときが増えるサーバーサイドでレンダリングするわけなので、当然CPU負荷が増える。Renderingについて知るべきこと。インフラ機械学習の前処理をやるバッチの処理時間が以前は20分くらいだったのにいつの間にか2時間かかっていた...ということがありました。処理時間を短かくする修正は入れたものの、処理時間がどれくらいかかっているかを継続的に監視する仕組みがそもそもないのが厳しいなと思ったのでそれについて書きます。完全にN番煎じなので、特に新規性はないです。songmu/horensoとはバッチの処理時間を記録したいけど、大掛りな仕組みは導入したくない。horensoでは実行したいバッチをwrapするような形で簡単に導入できる。input.txtこんな感じでラップすればよい。input.txtreporterは終了時に実行されるコマンド。自分の好きな言語で書ける。開始時刻と終了時刻から実行時間を計算して、Mackerelのサービスメトリックに投稿するreporterをGolangで書いた。horenso自体もGolangで書かれているし、MackerelのAPIをGolangから叩くmackerel-client-goもあるので、Golangだとしゅっと書ける。失敗したときにSlackに送るreporterとかも追加で指定することができる。元々のコマンド自体は何も変える必要がないのでgood。Mackerelで監視する実行時間がX分以上だったらSlackに通知する、といったreporterを直接書いてもよい。Mackerelに実行時間を投稿しておくと過去の傾向が分かるし、X分以上だったらSlackに通知するといった処理をMackerelに任せることができるので気楽。UIにアノテーションボタンを付けたい、でもユーザー管理機能は作りたくない(アノテーションするのは自分だけなので)。Gatewayを組み合せると簡単にできると聞いたので、やってみました。てこずったので正直あまり簡単ではなかったけど、やりたかったことはできたのでメモとして書き残しておきます。Gatewayで生やしていきます。Gatewayに生やしておくと後々の認証(Cognito)との接続がよいので、これを使います。Gatewayが何かを一言で説明するのは難しいけど、今回の用途に限れば裏側のロジックをLambdaで書きつつ、それをhttpで叩けるエンドポイントになってくれる君と思っておけばよい。別にlambdaじゃなくてもよいけど、今回はlambda。その他、リクエストをキャッシュさせたりといったこともできるようだが、今回の用途にはあまり関係ない。AWSロジックをLambdaに書く処理の本体はLambdaに書きます。Lambdaは色んな言語で書けるけど、手慣れているGolangで書きます。Gatewayの設定ロジックが書けたらaws-sam-cliを使って手元でテストしたりするとよい。start-apiとかやると手元でサーバーが走ります。applications動作確認ができたらsamを使ってLambdaにデプロイしていく。subnet内のRDSに接続する必要があったため、VPC内にLambdaを作った。samのテンプレートはこんな感じ。Gatewayのリソースも作られていると思う。Sharing)を有効にする必要がある。Gatewayの画面から「CORSの有効化」を選択、200のレスポンスヘッダーに以下のものを追加しておく。Cognitoの設定こことここを参考にしながらAWSコンソールでボタンをポチポチ押していく。ユーザープールとIDプールを作成していく。注意するところとしてこんな感じかな。認証プロバイダはCognitoだけで特に問題ないユーザーの登録はcliでやっておく。アプリクライアントの設定から「有効なIDプロバイダ」でcognitoを選択しておくAmplifyで認証されたユーザーのみにアノテーションボタンを見せる作成したユーザーがサインイン/アウトする画面はぐぐると色々出てくると思うので、それを参考に作る。今回は新しくユーザーがサインアップできる必要はなく、自分用のユーザーはcliで作成しているのでサインアップ画面は特に作らない。falseにして、それによって出し分けする。Gateway自体はインターネットで公開されているエンドポイントになっているため、誰でもエンドポイントを叩けばアノテーションをいじれてしまう。それでは困るので、API自体もCognitoで認証済みのユーザーのみ叩けるようにする。Role(arn:aws:iam::XXXXX:role/Cognito_YYYYYAuth_Roleのようなやつ)に追加で権限を付与する。invokeの権限を今回許可したいエンドポイントのみに与える。Gatewayの画面のオーソライザーから「新しいオーソライザーの作成」を選択。自分が作成したユーザープールを指定する。オーソライザーが作成できるとリソースの認証方法のCognitoが指定できるようになる。必須ではないと思うけど、「HTTPリクエストヘッダー」でAuthorizationを必須にしておくとよさそう。ここまで設定したらAPIのデプロイを行なって変更点を反映する。クライアント側の設定クライアント側は簡単。localStorageから必要なtokenを取得してきて、リクエストヘッダーに付けるだけ。}}困ってるところめちゃくちゃ困ってるというわけでもないけど、しばらくLambdaを起動させていなかった後の初回起動に時間がかかる。Interface)を作成する必要があるからだそうな。回避策としては定期的にポーリングしておくとよいらしいが、そこまで困ってるわけでもないので困りだしたらやる。論文読み会をやるので久しぶりに論文を読みました。久しぶりじゃダメなんだけど...。Researchの方が発表された内容です。発表スライド以下は雑なメモです。卓球10/24に開幕した卓球リーグ、Tリーグに観戦してきたので日記を書きます。京都から名古屋の武田テバオーシャンアリーナに、以下の3試合を観戦しにいきました。琉球アスティーダ練習時間の写真撮影は許可されていて、こんな感じでした。選手が目の前の通路を通っていく、うっかりサインをお願いしてしまう人もセキュリティ的に大丈夫なんかという気もしつつ、これだけ近いのはよいですね開場と同時に入場しても選手が開場で練習しており、間近で練習風景が眺められる小中学生以下の子どもの観戦が多い小さいときに一流のプレーを見て衝撃を受けるのはどういう道に進むのであれよい影響を受けると思っています試合が終わった後、めっちゃ笑顔になるこれだけいいプレーを見せてもらったら自然と笑顔になってしまう改善されるとよさそうな点あれこれ書いてますが、開場でもアンケートを取っていたのでそちらでも伝えています。クレームとかではなく、Tリーグがこれからも継続的に続く事業であって欲しいなと思うので、こういうところを改善されるといいんじゃないかと思ったところについても書いておきます。ダブルスも3セット先取でいいのではないか2セット先取だとあまりに一瞬で終わってしまった印象がある。試合全体が長くなりすぎないように考慮してのこともあるかもしれないハーフタイムは必要かどうか卓球経験者からするとハーフタイムが入ると緊張感が途切れてしまうので、ハーフタイムがないほうがいいなぁと感じた一方で、未経験者の人からすると2時間以上の試合を一気に見るのは集中力を使うため、観客への配慮でハーフタイムが導入されているのかもなというもしたグッズ売り場が狭い結構人気でサンプルを見るのに近づけない感じだった。売り場をもう少し広くして欲しい来客者数が読めなかったので、安全側に倒したんだろうなとは思う来場者数、もっと増えて欲しい!水谷、張本が出場する木下マイスター東京の試合はそれなりにお客さんがいたが、その他の試合は正直もっと席が埋まって欲しい。(1)スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。