「json」を含む日記 RSS

はてなキーワード: jsonとは

2022-09-04

パーサーコンビネーターっていつ使うの

これすげー面白いよね。

プログラム長いこと書いてて全然使った事なかったから楽しさを知らなかった。

でもこれ使う機会なくない?正直。

JSONとかメジャーフォーマットは既に誰かパーサー作ってるし、

正規表現で十分な場合圧倒的多数だし、

みんな何に使ってるのかな。

2022-08-27

anond:20220813040132

というけどさ、セキュリティ的に JSON を自前でパースする関数とか書きたくないだろ。俺だったら、string で受けて bignum とかに突っ込むだろうけど。

2022-08-13

プログラマー生産性は人により100倍くらい差があるというけれど

 割りとマジだよねと思う出来事をふと思い出したので書いてみる。

 といっても後輩が俺の思ってもいないところでつまづいて、それに俺がカルチャーショックを受けたというだけの話。

 問題の話なんだけど、とある有名サービスJSON APIを叩いて呼び出し結果を手元のオブジェクトマッピングするというただそれだけのコードを書くというもの

 普通に考えて一日もしないで出来ると思うような代物だけど、三日以上悩んで彼はそれでも出来なかった。

 何があったかというと、そのJSON API

{ ..., "count": 10000000000000000000000000000000000000, ...}

 という感じで多倍長整数リテラルとして書かれているのを前提として受け取る仕様だった。

 JavaScriptの通常の整数と違って、JSON整数リテラル仕様上大きさの制限記載がないので、上のようなのも合法

 で、彼の使ってたプログラミング言語オブジェクト から JSONの変換ライブラリが、多倍長整数文字列("")としてシリアライズするような仕様なことがわかって、彼は行き詰まった。

 そこで何をやり始めたかというと、JSON整数がそのまま1000000000000000みたいにシリアライズされるライブラリ探し始めたんだけど、それは見つからないまま。

 というわけで「増田さん、詰まってるんですけど……」と言われて助け舟出すことになったはいものの、彼のコード見るとJSON抽象構文木クラスがそのまま使えるようだった。

 なので、

String serialiaze(Ast.JsValue value) {
    return switch(value) {
        case Ast.JsNull nullValue-> "null";
        case Ast.JsInt bigIntValue -> bigIntValue.toString();
        case Ast.JsArray arrayValue -> arrayValue.stream().map(v -> serialize(v)).collect(Collectors.joining(", ", "[", "]"));
        // 他のJSONの木についても同様に処理
        default -> throw new RuntimeException("cannot reach")
    };
}

 1時間しない内にこんな感じのコード言語Javaじゃなかったけど、だいたいこういう感じ)を書いて無事問題解決。細かいタイポとかあるかもだけど、日記では確認してないのでそれはおいといて)。

 結局、JSONの形が期待と違って、しか既存APIじゃいいのがなかったのに延々API探すことしか出来なかったのが問題解決できなかった原因だけど、このくらいのは割りとちょこちょこある。

 きっと、それから一週間放置しても問題解決できなかっただろうし、どうも同じチームの同僚も問題解決できなかったようだった。

 最近APIは叩けるけど、そこでトラブルとどうにもならなくエンジニアにちょくちょく遭遇するんだけど、やっぱりもうちょっと基礎出来てないと駄目だなと思った出来事だった。

 具体的には、再帰が相性が良いプログラムを書けるとか、APIに頼れないときはさっさと自作する頭の切り替えとかもろもろ。

 それと、情報大学出てるのなら、せめて木構造に対してはサクっと再帰関数くらい書けてほしかったなと思う出来事だった。

2022-08-06

COCOAログ

つのまにかJSONで出力できるようになってたけど

そもそも仕様が公開されてなくて可視化できるのが有志のサイトしかない

・中身がエポック秒JSONが出力されても一般の人は意味不明なのでは?

というのはIT後進国を感じますね。デジタル庁なんとかして

人の集まるイベント系に行くとさすがに接触ログ結構出るけど普通にJSTに並べて表示してくれるだけでいいのに・・・

2022-07-19

anond:20220719164702

数年前ぐらいまではRails使ってるやつ多かったけど、最近フロントエンドのやつばっかだな。

JSON色付け係。

2022-07-17

山上徹也さんこと@333_hillさんのツイートアーカイブしました

リンクhttps://mega.nz/file/gclB0aLC#YICFsYuQBica-0Pis4sgj88GDwL6dzahfBJW2w2wc7E

消される前に。

APIで取得しています。1(リ)ツイートが1つのjsonファイルになっています

すべての情報が含めれる代わりに検索には不向きです。

何らかのデータ加工をして利用してください。

取得したのは今日20時ぐらいです。

2022-06-27

Core Keeper Dedicated Server を VPS 上に構築したときの手順メモ

Ubuntu 22.04 LTS x86_64 で構築。

CoreKeeper側で apt依存しているっぽいので、Ubuntu でやった方が楽だと思います

Tips

Ubuntu 20 TLS でやる場合、/home/steam/Steam/ が /home/steam/.steam/ になってたと思うので、環境に合わせて読み替えてください。

Install steamcmd dependent packages

dpkg --add-architecture i386
add-apt-repository multiverse
apt-get update
apt-get dist-upgrade
reboot

Create steamcmd User

useradd -m steam
passwd steam
gpasswd -a steam sudo

Steamcmd / Core Keeper Dedicated Server Install

sudo -u steam -s
cd
sudo apt install steamcmd
ln -s /usr/games/steamcmd steamcmd
./steamcmd +login anonymous +app_update 1007 +app_update 1963720 +quit

Run steamcmd (Install and Creating Core Keeper Dedicated Server system drectory )

cd ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/
./_launch.sh

Press Ctrl + C for Stop Core Keeper Dedicated Server

World file migration (if there is an old file)

mkmir -p -m 775 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds
chown steam:steam /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds

Copy old world file (0.world.gzip) to

/home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds

Copy old setting file (*.json) to

/home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/

chmod 664 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds/0.world.gzip
chmod 664 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/*.json

Backup setting

vi /etc/cron.hourly/corekeeper_backup

#!/bin/bash
cp -a /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds/0.world.gzip /home/steam/worldbackup/0.world.gzip.`date '+%Y%m%d%H%M%S'`
cp -a /home/steam/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/CoreKeeperServerLog.txt /home/steam/worldbackup/CoreKeeperServerLog.txt.`date '+%Y%m%d%H%M%S'`

chmod 777 /etc/cron.hourly/corekeeper_backup

sudo -u steam -s
cd
mkdir worldbackup

Start Core Keeper Dedicated Server

sudo -u steam -s
cd ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/
nohup ./_launch.sh
tail -f ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/CoreKeeperServerLog.txt

サーバースペック

利用者問題か、サーバー問題かわかりませんが人数が10人超えると CPU4コア/メモリ4G/100Mbps で結構ラグかったです。

今は CPU6コア/メモリ8G/1000Mbps で動かしています

不具合 (2022/06/28時点)

6-8人以上で2-3時間サーバー動かしてると、Unityライブラリがsegfault起こして、Core Keeper Dedicated Server が落ちます

ログ取れたのでバグレポしましたが、改善するまでは不特定多数が好き勝手するサーバーみたいなのを長期運用するのは厳しいかなと思いますタイミングによってはアイテムロストしてしまうので。

遊びで使うなら、ウォッチドック的なサービスを入れて、落ちたら適宜起動しなおすみたいな対応をした方がよいと思います

anond:20220626152712

はい、実際に動く増田書き込みミューChrome拡張を作ったよ。

manifest.json

{
  "name": "GomiMute",
  "version": "1.0.0",
  "manifest_version": 2,
  "description": "このゴミミュートするChrome拡張",
  "content_scripts": [{
    "matches": ["https://anond.hatelabo.jp/20220626151746"],
    "js": [
      "main.js"
    ]
  }]
}

main.js

document.querySelector(".body .section").innerText = "みゅーと";

2022-05-14

Railsが死んだのはわかった。では何使えばいい?

現代Webアプリケーションフロントエンドが中心で

バックエンドJSON返すだけの存在になったのはわかった。

からRailsやLaravelみたいなフルスタックフレームワークが捨てられてるのもわかった。

では何使えばいいのかよくわからん

Firebase? AWS Lambda?

Go流行ってるらしいけどGoEchoってやつを使えばいいのか?

2022-02-28

anond:20220228122943

Evcel VBA活用するメリット

そんなExcel VBAですが、当然メリットデメリットがあります。主なものを挙

ます

メリット1・備わっているExcel機能だけでは実現できない処理が実現可能

最大のメリットがこれです。

例えばボタンを押したら処理が走る、なんて機能にしても、VBAボタンを押し

ときの処理のコードを書かなければ実現できません。

VBAExcelを使うにあたり必須なのです。

メリット2・計算処理をまとめられる

大規模なExcelファイルになると、いろいろと凝った計算処理が出てきます

こっちのセルを参照し、そっちのセルを参照し、二つの結果に処理を施し…など

のような事例です。

Excelの式で書くのが厄介になってくる場合があります。というか、たいていそ

うです。

そんなとき計算処理をVBAにすれば、複雑な計算も見やすく書けますし、後々

メンテナンスもしやすいです。

メリット3・大規模なシステムが開発できる

VBAでできることは、Excel機能にとどまりません。

Windowsのコアな部分の機能を使ったり、外部のテキストファイルログファイ

ル、JSONファイルHTMLファイルなど)やACCESS連携することもできます

これらを活用すれば、Excel実用に耐える大規模システムの一部になるのです。

そのような大規模システムは、一般的にはエンジニアの手によって開発されま

す。しかし開発言語はVBAです。

メリット4・同一の処理を一つのコードで済ませられる

同じExcelファイルの中に、同一の処理が散在していることはよくあります

そんなときVBAを使ってコード記述し、VBAを呼び出すようにしておけば、処

理の内容がコードの中に局所化されます

これも、VBAメリットの一つです。

Evcel VBA活用するデメリット

次にデメリットを挙げます

デメリット1・VBAを知っている人でないとメンテナンスできない

当然ながら、VBAを含むExcelファイルメンテナンスするのにはVBA知識が必

要です。

ある程度体系化して覚える必要があります

学習コスト比較的低いですが、ゼロではありません。

すると、作成者がいなくなると誰もそのExcelファイルメンテナンスできな

い、なんてことが起こり得ます

メンテナンスしなくてもいいITシステム存在しないので、これは大きなデメ

リットです。

VBAを他の人も学習すればいいのですけどね。

デメリット2・表の仕様変更に弱い

筆者が最大のデメリットだと感じているのはこれです。

セル参照であれば、ある範囲セルを削除したり、逆に挿入したりすると、参照

先のセル勝手に調整されます

ところが、そのセルを使うVBAコードには調整は一切かかりません。手作業

参照先を調整する必要があります

ここの問題は仕方がない部分ではあるのですが、実際なんとかしてほしいところ

です。一つでも調整を忘れると、とたんにコード全体が正しく動作しません。

2022-02-27

anond:20220227164150

JSONは一行のレコードの中にいくらでも多次元配列入れれるってところが大きいかなぁ。CSVじゃその表現は無理だろうし

anond:20220227162851

データ処理でたまにたびたび出てくるけどJSONってどう扱うの?

CSVとの違いがわからん

anond:20220227162101

「大量に出てくる測定装置から吐き出されるデータ」の形式はどういうものなのかな

例えばCSVとかJSONとかのテキストファイルなら、だいたいどの言語でもなんとかする方法はあると思う

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービスAWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス

App Runner

 2021年5月GA(一般公開)となったサービスプロダクションレベルスケール可能webアプリを素早く展開するためのマネージドサービスGithub連携してソースコードをApp Runnerでビルドデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。

 ECSとFargateの場合ネットワークロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である

ECS Fargateを利用した場合コスト拡張性、信頼性エンジニアリング観点

コスト

EC2より料金は割高。ただし、年々料金は下がってきている。

拡張性】

デプロイの速度 遅め

理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる

理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。

タスクに割り当てられるエフェメラストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要場合はEFSボリュームを使う手もある。

割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリ要求するホストとしては不向き

信頼性

Fargateへのsshログインは不可。Fargate上で起動するコンテナsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境sshの口を開けるのはリスキーである。他にSSMセッションマネージャーを用いてログインする方法もあるが、データプレーンEC2の時に比べると手間がかかる。

しかし、2021年3月Amazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。

エンジニアリング観点

Fargateの登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2022-01-20

機械学習エンジニアコード汚すぎワロタアァ

なんだこれは

anond:20220120011019

pugみたいな5分で文法分かって

package.jsonに2行書けば導入できるようなツールを「技術」とか言ってる時点で無理だと思う

sassとかは難しいけどpugだぞ?分かってるのか?

こういう導入の簡単しか考えられない無能技術負債を積み上げていく

anond:20220120010619

pugみたいな5分で文法分かって

package.jsonに2行書けば導入できるようなツールを「技術」とか言ってる時点で無理だと思う

sassとかは難しいけどpugだぞ?分かってるのか?

anond:20220120001906

俺もわからないw

素のPHPみたいな方がHTMLとしてプレビュー編集できるし、

ツールはみんなHTML形式には対応しているけど、非HTML形式テンプレートには対応してないわけで、

JSONみたいに書けるんだぜ、とか、Pythonみたいにインデントするだけだぜ、みたいなのは

プログラミング言語マニア自己満足っぽい気がする

言語思考規定する、とか、流れるように書ける、とか、どうでもいいというか、

寧ろ、ツール群が揃ってるとか、つまらないほど使えて当たり前の方が開発は安定する

と、さっきまでNim書いてたフラストレーションもあって思いました

2021-12-21

涼宮ハルヒパッケージ管理

消失最後の方で、たしかキョン長門の恋心?が理解できてるのかよく分からんが、

長門がいない世界になったとしても、ハルヒ長門存在するように考えさせるみたいなことを言ってた気がするが、

当たり前だが、あの世界はハルヒが神みたいな前提で成り立ってるわけだが、

キョン長門だけでなく、すべての人、というか物質存在ハルヒによって成り立っているといっても過言ではない

まり、package.jsonだかgo.modだかcomposer.jsonだか使ってる言語にもよるわけだが、

すべての依存関係涼宮ハルヒと書かれてるようなわけであり、

まり、すべてのソフトウェア依存しているそのモジュールが改変されれば、

すべてのソフトウェアが影響するのと同じであり、

したがって、攻撃者は涼宮ハルヒに細工すれば、世界を思うがままに改変できるということである

まり涼宮ハルヒ洗脳するとか、思考誘導するとか、

なんらかの方法自分の意のままに考えさせることができるようになれば、

攻撃者は世界を思うがままに改変できて、それはそれで楽しそうに思えるのだった

俺がキョンならそれを試みると思うのだ

はぁ…

現実逃避終わり…

2021-12-11

anond:20211211003902

CSVでくれっていうコメントがあるけど、俺の感想はそれに近い

社内でしか公開しないエンジニアしか見ないプロトタイプみたいなもの場合そもそもプロトタイプ目的デザイン完璧さを求めることではないのでjsonでもcsvでもいいかAPIの生情報を見せろということはある

なのでどういうデザインがいいかっていうのはかなり文脈依存問題かもしれない

2021-11-12

anond:20211112091935

package.jsonとtsconfig.jsonは事前に見せてもらおう。パパと約束だぞ。

2021-10-18

なんでそんなにRails嫌いなん…?

わざわざRailsにReact乗せる理由コンテンツリッチ化以外に理由ある?

API化するかしないかってreturnがHTMLJSONかの違いかしかいから、やりたかったらフロントをReactにすればいいと思うけど、今回急ぎなんでしょ…?

2021-09-25

オブジェクト指向はすでに粒度時代にあっていない」を読んで

記事

@kis (id:nowokay) さんの以下の記事についてです。

https://nowokay.hatenablog.com/entry/2021/09/25/042831

ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身理解を助けるためにも言わんとしていることを推測しつつ、自分認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。

前提

まずは前提を書いておかないと論点がぼやけると思うのでいちおう。

自分バックグラウンドは以下:

その他の前提:


本文およびブコメを読んで思ったこ

2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります

関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドプログラムパフォーマンスに影響を与えるので、パフォーマンス要件がをシビア場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスネットワークアクセスレイテンシが大きいので、そうした相対的に細かいオーバーヘッド無視しても(大抵の場合は)問題にならなくなった、というのが「時代」の流れなんだという認識です。

いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体モジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます

記事にもありますが、RPC派生実装?)として生まれJava の CORBA や MicrosoftDCOM みたいな振る舞い付きのオブジェクトコンポーネント)を共有しようという世界観は廃れ、REST API のような単一の振る舞い(エンドポイント)とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション通信の潮流と、計算資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。

まり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。

なので、以下のコメントちょっと論点がずれてると思いました。

はあ?「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わりますオブジェクト指向とはほぼ無関係です。

https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin

なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない

https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang

しかに、アプリケーション単位アプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います

ソフトウェア記述をまとめるという視点では主にステートレス関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理やすくするという視点ではオブジェクトというのはライフサイクルリソース管理視点が足りず小さすぎる、ということで、オブジェクト指向粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います

個人的にわからなかったのは以下の部分です。

オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない?」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。

当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの?」って思ってしまますオブジェクト指向定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェア組織化すること」なのであれば)。

おわりに

Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論収束に向かってほしいと個人的には思います(とっくに収束していると感じている方もいらっしゃるでしょうけど)。

https://gist.github.com/posaunehm/4087971

ログイン ユーザー登録
ようこそ ゲスト さん