gigazine.net Intelは既にXeonとアルテラFPGAをワンパッケージにした製品を出していたはずだけれど、それと何が違うのだろう
データ共有にレジスタを使うというあたりか？
www.itmedia.co.jp speech recognitionに食わす。それはそう。
やはり、行動というかリクエスト履歴を元にアノマリ検知するしかないのかなぁ。
2020年を振り返る
2020年もありがとうございました。
友人が常々「アイマスで受けたこの感情はいま書き残しておかないと記憶の彼方に紛れて消えてしまうんだ」と言っていたのが印象に残っていて、僕個人としても何か出力を残しておきたいと思ったので、2020年を振り返ってみることにする。
アイマス
総じて、我慢の年だった。
開催できたのはデレ7th大阪まで、それ以降中止になってしまったものは枚挙にいとまがない。
大きなものだけでもミリクルーズや、SideMプロミ、シャニスプフェス、シャニ2nd、SideM5th、ミリ7th、9月予定だったデレステ5周年記念ライブ…そして年明けのデレHappy New Yellも残念ながら無観客になってしまった。
5ブランド合同プロミもゆくm@sくるm@sでまだ企画継続中と言及されたのみで具体的なものは何も見えていない。
アイマスのファンコミュニティを分類するとどう考えてもコア層に分類されるであろう僕としては、去年までと同様のアイマス濃度を維持して生きるのはやはり難しい年だった。
二次創作の一形態としてやっていたアイマスDJも今年はほとんどできなかったし、その繋がりで手伝い始めたISF系の同人即売会も今年は中止になってしまったり。
一方で、カジュアル層の人たちがアイマスに触れるハードルは今年は下がったと思う。
アイマスのコンテンツの魅力としての大きな柱である過去のライブの映像を無料配信したり、シンデレラの24h生配信であったり。
アイマス専用のYouTubeチャンネルを開設したり、ポップリンクスを発表したり。
これまでのアイマスは課金ユーザ平均課金額の高さに頼りきりで、裾野、あるいはカジュアル層の取り込みが下手というのは以前から常々思っていて、一方よく比較されがちなラブライブ！はそれが上手いなあ、とずっと羨ましく思っていた。
その最たる例がベストアルバムの売り方だと思っていて、ラブライブ！は初代の第一期の際に3000円でほぼ全曲揃うベストアルバムを出しているのだけれど、アイマスはアニマスの1年前に765+876=!! Vol.1、アニマスの2年後、シャイニーフェスタの1年後にGRE@TEST BEST!のHISTORYが発売という感じ。 既存曲が多すぎるというのもあるが、それにしたってタイミングがアニメ放映合わせですらないのは新規層を取り込む気があるのか？と思った記憶がある。
もっとも、それは公式も認識していたようで、デレアニの際にはANIMATION PROJECT 00としてシンデレラプロジェクト14人のCINDERELLA MASTERのソロ曲を集めたCDが発売されたりしている。
話が逸れてしまったが、新型コロナウイルスのワクチン開発などによって一旦落ち着きを見せ、安心して移動できるようになって以降も、YouTubeチャンネルやポップリンクス、ライブビューイングよりも更にハードルが低い自宅で視聴できる有料生配信などの取り組みを通じて、カジュアル層がアイマスに触れるハードルを低くし、ファン層の裾野がもっと広がってくれるといいなぁ、と願っている。
ゲーム
家から全く出れない日々だったので、アイマス以外のゲームのプレイ時間が去年と比べて圧倒的に増えた。
後述するが仕事が完全に自宅勤務となり、友人たちとゲームをするとかでもないとついずるずると働き続ける感じになってしまいかねなかったので、退勤する理由としてもちょうどよかったと言える。
Call of Duty : Modern Warfare
CoDシリーズはXbox360のMW2以来なので10年ぶりか。
元々は友人宅で友人がWarzoneをやっているのを見て懐かしいなぁ、と言っていたくらいだった。
それがマルチプレイヤーの無料期間をやって久々にFPSの楽しさを思い出し、二人目として買って以降、友人内で一気に増え、6人フルパーティが比較的容易に作れるくらいの人数まで増えたので楽しかった。
キルタイムの短さ的に待ちがとても強いので、専らドミネーションだけで遊んでいた。
CoD BO:CWも一応買ったが、ほとんどできていない。
eBASEBALLパワフルプロ野球2020
これもCoDで述べた友人の影響。
にじさんじ甲子園にだいたい準拠したルールの、アイマスのアイドルを選手とした大会を友人内で開催していて、その第一回の決勝戦を見てやりたくなったので買って第二回に参加した。
リソース管理ゲームが好きな一方、パワプロは投球操作や打撃操作が難しくて敬遠していたのだけれど、栄冠ナインはそれらが要求されないのでとっつきやすかったのもあると思う。
野球は観戦ができる程度にはおおまかなルールを知っていたが、インフィールドフライの理由はこれで理解したりした。
暇があるのかという問題はあるが、来年はいくらか現地での野球観戦もしてみたいと思っている。
Apex Legends
VTuberの人たちがやっていたので存在は知っていたが、実際にやり始めたのはCoDをやっていた面子がやっていたからで、シーズン5でちょっと触れて本格的にやり始めたのはシーズン7から。
CoDと違ってキルタイムが長いので押し引きや仕掛けるタイミングなどの戦術レベルの判断に加え、戦略としてのジャンプの分布、ルート取りなど考えることが圧倒的に多い難しいゲームだけど、ギリギリ考えられるくらいの情報量に抑えられているのはすごくよく出来ているなと思う。
まあ、ランクマ金3～4あたりなのでやり込んでいるとまでは言えないが、それなりに楽しんでいる。
Frostpunk
これは個人でこの年末にsteamで買ったもの。
詳しいゲーム内容は下記記事に譲るとして、とても面白かった。 game.watch.impress.co.jp
かなりシビアなリソース管理ゲームで、警告が出てからの対処はかなり難しく、容易に詰みうる。
リソースの中でいかに危機を未然に防ぐか、という戦略の組み立てが必要で、それが面白かった。
あまりにも熱中しすぎた結果、買ってから98.5時間のうちに68.9時間プレイとかしていた。
Superliminal
リリース当初に話題になっていたのを見かけた、錯視を利用したパズルゲーム。 現実世界では絶対に実現できないギミックが多数で面白く、一気にクリアしてしまった。
ただ、現実世界では絶対に実現できない錯視ギミックなので、少し3D酔いをしてしまったので苦手な人は注意が必要かもしれない。
アニメ
普段は全然書かないが、アニメもそこそこの本数見ている。
ほぼ全てをdアニメストアで見ていて、仕事中ではなくアニメを見るときはアニメだけに集中している。
ただ、等速では情報密度が低くて思考が暇を感じてしまって逆に集中できないのでほとんど倍速再生で見ている。1.25倍速か1.5倍速が多い。
まず、2クール連続アニメで2019年第四クールから継続し、完走したものが下記。
- ソードアート・オンライン アリシゼーション War of Underworld
- Fate/Grand Order -絶対魔獣戦線バビロニア-
- 僕のヒーローアカデミア
- 本好きの下剋上 司書になるためには手段を選んでいられません
4本。
つぎに、今年放映開始の新作で完走した、あるいは完走しそうなものが下記。
- 攻殻機動隊S.A.C 2045
- ドロヘドロ
- 痛いのは嫌なので防御力に極振りしたいと思います。
- 虚構推理
- ダーウィンズゲーム
- プランダラ
- へやキャン△
- ＜Infinite Dendrogram＞-インフィニット・デンドログラム-
- 異世界かるてっと2
- 異種族レビュアーズ
- ID : INVADED イド：インヴェイデッド
- SHOW BY ROCK!!ましゅまいれっしゅ!!
- 乙女ゲームの破滅フラグしかない悪役令嬢に転生してしまった…
- 八男って、それはないでしょう！
- プリンセスコネクト！Re:Dive
- グレイプニル
- 社長、バトルの時間です！
- 球詠
- 魔王学院の不適合者 ～史上最強の魔王の始祖、転生して子孫たちの学校へ通う～
- 炎炎ノ消防隊 弐ノ章
- 宇崎ちゃんは遊びたい！
- デカダンス
- 天晴爛漫！
- 「銀河英雄伝説 Die Neue These 星乱」
- 呪術廻戦
- ダンジョンに出会いを求めるのは間違っているだろうかⅢ
- キミと僕の最後の戦場、あるいは世界が始まる聖戦
- 100万の命の上に俺は立っている
- 無能なナナ
- 戦翼のシグルドリーヴァ
- 『ヒプノシスマイク-Division Rap Battle-』Rhyme Anima
- ラブライブ！虹ヶ咲学園スクールアイドル同好会
- いわかける！- Sport Climbing Girls -
- 禍つヴァールハイト -ZUERST-
35本。
列挙してみると本当に結構見てることに気付く。
実際にはこれに加えて途中で観なくなってしまったものとか、気が向いたとかで一気見した既存作などがあるのでもっと見ていることになる。
個別に言及しようとすると全部にコメント付けようとして未完になるのが僕の常なので個別の言及はしないことにする。
あとは 下記記事にも書いたが、ヴァイオレットエヴァーガーデンも見た。 fusagiko.hatenablog.jp
SHIROBAKOの劇場版も見たかったが…時期が時期だったので外出自粛のまま機を完全に逃してしまったので残念。
その他娯楽
バーチャルYouTuberと呼ばれている人たちの配信を見聴きする機会がとても増えた。
アニメと異なり、こちらはながら見のほうが多い。
会社の性質もあって元々VTuberの人たちには好意寄りの特定のファンではない裾野くらいの立ち位置だったのだが、今年初めてファンであると言えるような人ができた。
まあ、個人事業主勢だったからなのか隙が多かったというか迂闊というか、放火されてしまって今はほとんど配信も何もしていないのだけれど、今でもメンバーは解約してないし、生きていてくれているならばそれで良い。
仕事、あるいはWebサービス開発者として
緊急事態宣言より前の2月中旬からずっと自宅勤務をしている。
もともと東京オリンピックによる混雑の回避を目して週1の自宅勤務を去年の10月ごろから試していたので、突然自宅勤務になった会社の人たちよりは幾分か混乱せずに済んだ。
会社のオフィスが6月ごろにリフォームされたのだが、ずっと自宅勤務なのでリフォーム前の荷物退避とリフォーム後の荷物格納の2回しか行っていないのは少々もったいない感じもする。
自宅勤務になって変化したことといえば、通勤時間が要らなくなったこともあるが、それよりなにより、圧倒的に労働時間が増えた。
僕の性質として、気になることがあるとそれを倒す、あるいは出力するまで頭の中が占有されてしまってほかに何も手に付かないという傾向がある。
また、起きて真横に仕事できる環境が存在するので、起きたら朝食を摂りながらslackの未読に目を通して…とかしていた結果、自宅勤務前と比べて労働時間が1.5倍くらいになってしまった。
あまりにも長時間やりすぎて直上の上司からやんわりと注意を受けてしまったくらいだ。
それに区切りをつけるためにも、前述した「みんなでdiscordに集まってゲームをする」というのはちょうどよかった。
また会社でなく僕個人としてはそろそろ自分から若いとは言えない年齢になってきたので、格好つけて言えばWebサービス開発者としての自分のブランディングというか、万が一転職の機会が巡ってきたときに人となりをわかってもらうため、あるいは会社への自分の価値のアピールなどとしてコード以外の出力を増やしたいと思っていた。
その一環として、今週読んだ記事というのを始めた。
兎にも角にも習慣をつけなければ三日坊主に終わってしまうので、週ごとに読んだ記事のURLを羅列するだけという、ハードルを極限まで下げた目標にした。
気が向いたらカテゴリ分類したり、短いコメントを付けたりするが、それはあくまで追加目標であって、とにかく続けることが大事。
チーム内で雑談するときのネタ庫としても意外と機能している。
本当はOSSに継続的にcontribute出来ていたりするとカッコイイのだけれど、それは最近できていない。
2017～2018年ごろはマストドンにそこそこ積極的にPRを送っていたが、今は必要と思しき機能はだいたい入り切って保守フェーズに至った印象があり、少し離れてしまっている。
というわけで
あまりにも取り留めがなさすぎて文章としても成立しているかというと怪しいですが、2020年もありがとうございました。
来年も変わらず宜しくお願いします。
今年もあと7時間と少しになりましたが、よいお年を。
今週読んだ記事 2020/12/7～2020/12/13
Ruby / Rails
github.com ActiveMailerにSESを追加するためのもの、というイメージが強かったが、いつのまにか色々な機能が増えていた。
後述する、lambdaでdockerイメージを使える機能と組み合わせた、active jobのlambdaバックエンドはうまく管理する方法を考えられれば検討に値しそう。
AWS
今月はre:Inventが開催中であることもあって、AWS関連の諸々が非常に多い。
aws.amazon.com dev.classmethod.jp lambdaがdockerイメージをサポートした。 これまでlambdaのデフォルト実行環境にない共有ライブラリを使用したりする際にはlambda layerなる独自のレイヤを重ねなければならなかったことを考えると簡単になったと言える。
その他
AWS SSMのパラメータストアから環境変数へパス指定で秘密情報を一括展開する
この記事は第二のドワンゴ Advent Calendar 2020 12月7日の記事です。
要するに
- dockerコンテナ化されたサーバアプリをAWS ECS上で起動する際、パラメータストアから環境変数へ秘密情報を一括展開したい
- ECSにネイティブでパラメータストアから環境変数へ展開してくれる機能は存在するが、パラメータストア上のパラメータと環境変数との対応関係をいちいち書かなければならず絶妙に手間がかかり使いづらい
- パラメータストアから一括展開してくれるような単機能のgolangのワンバイナリを作るとお手軽なのでgithub.com上にたくさん存在するが、たくさん存在しすぎてどれもデファクトスタンダードになれず、メンテされているか怪しいものばかり
- そこで、AWS CLIからの出力をjqを使ってbashのexport形式に整形し、それをevalしてしまえばメンテ要らず
- なおコンテナイメージのサイズ肥大には目をつぶるものとする
詳しく
AWSのSystem Managerにはパラメータストアという機能があります。
これはサーバサイドアプリケーションの動作に必要な各種の設定情報を、必要であれば暗号化とともに格納しておける機能です。
一方で、サーバサイドアプリケーションをサービスインフラ上で動作させる方法のガイドラインの有名なものにThe Twelve-Factor Appがあり、その中で環境ごとに異なる設定情報は環境変数から注入せよ、という方針が示されています。
これは特にサーバサイドアプリケーションをdockerコンテナに包んで動作させる際に重要です。
この2つを合わせて考えると、パラメータストアに格納されている値を環境変数へ展開した後でサーバサイドアプリケーションを起動したくなってきますよね。
ECSによるパラメータストアから環境変数への展開
実はAWSのコンテナオーケストレーションサービスであるところのECSには、その機能があります。
じゃあそれでいいんじゃないか、と思いきや、これが絶妙に手間がかかる。
{ "containerDefinitions": [{ "secrets": [{ "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" }] }] }
Systems Manager Parameter Store を使用して機密データを指定する - Amazon ECS
というように、ECSのコンテナ定義の中に展開後の環境変数名と展開元となるパラメータストアのパラメータのarnを両方書かなければならないんですよね。
これがどのように困るかというと、
- サーバサイドアプリのコード上で新たな設定値を環境変数から読み込むようにする
- パラメータストア上にパラメータを作成する
- コンテナ定義を更新し忘れる
- コンテナ定義を更新し忘れているので当然環境変数に展開されなくて動作せず、首をかしげる
となるわけです。
新たな設定値を作るのなんてそれほど多いわけではないけれどたまにある、くらいの頻度なので余計にうっかりしてしまいやすく。
golangのワンバイナリで展開
次に思いつくのが、パラメータストアから環境変数へ展開するだけの単機能の実行ファイルをgoあたりのワンバイナリで書き、使う方法でしょう。
これは本当にお手軽な方法で、お手軽がゆえに様々な人が思いついてそれぞれが作っています。 知ってるだけで6個もある。
github.com github.com github.com github.com github.com github.com
そしてお手軽すぎてそれぞれが作ってるがゆえにどれもデファクトにはなっておらず、残念ながらメンテされているのか怪しいものばかり。
AWS CLIとjqを使う
そこでこの記事の本題。
AWS CLIとjqを使って展開してしまいましょう。AWS CLIはAWS謹製なので当然メンテされていますし、jqも汎用ツールです。
具体的にはこのようにします。
これが何をやっているかというと、まずaws ssm get-parameters-by-pathサブコマンドの出力は下記のような形式になっています。
$ cat response { "Parameters":[{ "Name": "/service_name/dev/HOGE", "Value": "hoge\\nvalue" },{ "Name": "/service_name/dev/FUGA", "Value": "fuga value" }] }
これのParametersキーの内容を各オブジェクトに分解し…
$ cat response | jq -r -c '.Parameters[]' {"Name":"/service_name/dev/HOGE","Value":"hoge\\nvalue"} {"Name":"/service_name/dev/FUGA","Value":"fuga value"}
jqのstring interpolation記法を使ってbashのexport形式に加工しています。
$ cat response | jq -r -c '.Parameters[] | "export \(.Name|split("/")[-1])=\"\(.Value)\""' export HOGE="hoge\nvalue" export FUGA="fuga value"
もう少し詳しく説明しますが、まず\(～) がjqのstring interpolation記法です。
.Name|split("/")[-1]の部分はNameキーの内容を"/"でsplitし、その配列中の末尾要素を取り出しています。これが展開後の環境変数名となります。
Valueキーの内容はそのままでよいので単に.Valueです。
.Valueの前後の\"は単にエスケープしたダブルクオーテーションであって、これはjqのstring interpolationがダブルクオーテーションでなければ動作しなかったためにエスケープが必要でした。
というわけで、このbashスクリプトをこれをサーバサイドアプリケーションの起動直前にevalすれば、パラメータストアから環境変数へ秘密情報を展開した状態で起動できます。
そうすると、コンテナ定義に書くのは下記だけで良くなります。
{ "containerDefinitions": [ { "environment": [ { "name": "AWS_PARAMETER_STORE_REGION", "value": "ap-northeast-1" }, { "name": "AWS_PARAMETER_STORE_PREFIX", "value": "/service_name/dev/" } ], } }
パラメータの追加時も単にパラメータストアに作成するだけで、コンテナ定義を編集する必要はありません。
ついでに、/service_name/以下を編集する権限をそのサービスの開発チームに付与すれば、設定値を変更する権限を安全に移譲できます。
実際、僕の仕事の担当サービスではマイクロサービスとまでは行かないものの複数のサブシステムが存在するため、それぞれの開発者にサブシステムの名前空間だけを編集する権限を移譲しています。
これを動作させるためにはECSコンテナにタスクロールとして与えるIAMロールにおいて下記アクションの許可が必要となります。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssm:GetParametersByPath", "kms:Decrypt" ], "Resource": [ "arn:aws:ssm:<region>:<aws_account_id>:parameter/<parameter_name>", "arn:aws:kms:<region>:<aws_account_id>:key/<key_id>" ] }, { "Effect": "Allow", "Action": [ "ssm:DescribeParameters" ], "Resource": ["*"] } ] }
なお、この方法には明確な弱点があって、jqとAWS CLI、そしてAWS CLIの依存であるpython3をインストールしなければならない関係で、コンテナイメージのサイズが肥大します。具体的には60MBほど。
つまり、
- ECS公式の環境変数展開の絶妙な使いづらさ
- 自分でgoのワンバイナリを保守する手間
- メンテされているのか不明な自分以外の人のワンバイナリを使うリスク
- コンテナイメージのサイズ肥大
を天秤にかけた結果、最後のコンテナイメージ肥大を許容してAWS CLIとjqを使う方法に落ち着いたわけです。
ついでにパラメータストアへのパラメータ作成もterraformで簡単にする
これで設定値の追加時にコンテナ定義は編集しなくてよくなったわけですが、パラメータストアへのパラメータ作成もterraformで簡単に.してしまいましょう。
具体的には下記のようにします。
resource "aws_ssm_parameter" "parameter" { for_each = var.app_environment_variables type = "String" name = "/${var.service_name}/${var.env}/${each.key}" value = each.value } variable "env" {} variable "service_name" {} variable "app_environment_variables" {}
var.service_nameにはサービス名を、var.envには環境名を渡しましょう。今回の場合はservice_nameとdevですね。
そして、var.app_environment_variablesに下記のようなmapを渡してあげると、既に示した例で出てくるような、パラメータがパラメータストア上に作成されます。便利。
module "parametor_store" { env = "dev" service_name = "service_name" app_environment_variables = { HOGE = "hoge\nvalue" FUGA = "fuga value" } }
一つ注意しなければならないのが、aws_ssm_parameter.parameterのtypeをStringにしているため、パラメータストア上に平文で保存される点です。
これをSecureStringにするとkmsの暗号鍵で暗号化して保存できますが、terraformで書くと結局平文の値がtfファイルやtfstateに書かれることになってしまうため、SecureStringにする意味が薄くなってしまいます。
そのため仕事では、SecureString型にする必要があるようなデータベースへの接続パスワードなどについてはあえてterraformで管理せず、Webコンソール上から直接手で作成しています。
何か良い方法があったら知りたい。
おわりに
というわけで、AWS SSMのパラメータストアから環境変数へパス指定で秘密情報をAWS CLIとjqを使って一括展開する方法でした。
本当はECSがパス指定からの一括展開をネイティブでやってくれるようになればこのようなことはやらなくて良いのですが！
なにとぞ、どうにかなりませんか、AWSさん！！
