  |
はてなキーワード: Applicationとは
https://chat.openai.com/share/c80d83ea-752b-4561-a162-7ea0bd116d56
Option Explicit
Dim objExcel, objWorkbook, objWorksheet
Dim strFolderPath, strSourceFile, strTargetFile, strSearchString, strReplaceString
Dim intLastRow, intRow, intColumn
Set objExcel = CreateObject("Excel.Application")
strFolderPath = ".\" ' スクリプトと同じフォルダにあることを仮定
strSourceFile = "変更一覧.xlsx"
strTargetFile = "変更一覧.xlsx"
Set objWorkbook = objExcel.Workbooks.Open(strFolderPath & strSourceFile)
objWorkbook.Sheets("1月").Copy , objWorkbook.Sheets("1月").Index
objWorkbook.Sheets("1月 (2)").Name = "2月"
' セルの値の置換
Set objWorksheet = objWorkbook.Sheets("2月")
objWorksheet.Cells(1, 1).Value = Replace(objWorksheet.Cells(1, 1).Value, "1月", "2月")
objWorksheet.Cells(2, 7).Value = Replace(objWorksheet.Cells(2, 7).Value, "2023/2/14", "2023/3/14")
' 最終行の取得
intLastRow = objWorksheet.Cells(objWorksheet.Rows.Count, 1).End(-4162).Row ' xlUp
' 値のクリア
For intRow = 8 To intLastRow
For intColumn = 1 To 6
objWorksheet.Cells(intRow, intColumn).ClearContents
Dim objFSO, objTextFile, strContents, arrLines, arrFields, strNewContents
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.OpenTextFile(strFolderPath & "変更一覧.txt", 1)
strContents = objTextFile.ReadAll
objTextFile.Close
arrLines = Split(strContents, vbNewLine)
For Each strContents In arrLines
arrFields = Split(strContents, ",")
For Each strContents In arrFields
If IsNumeric(strContents) Then
strNewContents = strNewContents & "'" & strContents & ","
Else
strNewContents = strNewContents & strContents & ","
End If
strNewContents = Left(strNewContents, Len(strNewContents) - 1) & vbNewLine
' データをシートに貼り付け
Set objWorksheet = objWorkbook.Sheets("2月")
objWorksheet.Cells(1, 8).Value = strNewContents
' セルの値の置換
objWorksheet.Cells(123, 1).Value = Replace(objWorksheet.Cells(123, 1).Value, "F", "FH")
objWorkbook.Save
objWorkbook.Close
objExcel.Quit
ごめんね。内部ストレージもいっぱいですってエラーがでるのでなんとかしてほしいといわれて、ストレージにある動画とか画像とか逃がしてるうちに
強制プリインストールされているキャリアアプリ系の謎のエラーメッセージに気づく。これはアレをすれば解決するか(・・?そうおもった。削除したいアプリ一覧とかいうのを 参考にして、ドコモ電話帳
DOCOMO Initialization
docomo Application Manager
dアカウント設定
dメニュー
my daiz
などを削除したら、泣かれた。電話もできなくなったっていわれた。ごめんなさい。なぜだろう(・・?けっこう騒がれてつらみしかない。今朝はあそこに立寄ってから出社したいから、お小言にずっと耐え忍ぶのか？
GPT-4 AI Tutor Prompt: A tool for creating personalized learning experiences using GPT-4 and LangchainJS, a drag and drop UI for building LLM flows.
Pandas AI: A Python library that adds generative AI capabilities to Pandas dataframes, making them conversational.
FigmaChain: A set of Python scripts that use GPT-3 to generate HTML/CSS code from Figma designs. It also has a chatbot interface for interactive code generation.
Sui: A smart contract platform with high performance and an asset-oriented programming model based on the Move language.
Jailbreak for ChatGPT: A project that allows ChatGPT to predict the future, opine on controversial topics, and assess what is true. It may help us understand LLM bias.
ML Observability in a Notebook: A tool to uncover insights, surface problems, monitor, and fine-tune generative LLM, CV and Tabular models.
System Design Primer: A resource to learn how to design large-scale systems and prepare for the system design interview. It includes Anki flashcards.
Next.js 13 App: An open source application that showcases the new features of Next.js 13, such as router, server components, and more.
TypeScript: A superset of JavaScript that compiles to clean JavaScript output.
Media Downloader: A desktop utility to download images/videos/music/text from various websites, and more.
AI Pull Request Fixer: A tool to fix issues with AI-generated pull requests, powered by ChatGPT.
Chat Chat: An app that lets you deploy your own AI interface and chat with different LLMs in one place.
はてぶの上位にちょいちょい載ってるTBS系のニュースサイト、newsdig.tbs.co.jpについて。
https://b.hatena.ne.jp/site/newsdig.tbs.co.jp/
何がヤバいかって、くっそ巨大なCookie(LocalStorageとかも含むのか知らんけど)をしこたま保存してんのよ。
気付いた時点では640MBも占有してた。別に巡回チェックしてるわけでもなく、話題に挙がってたら見てみることもある程度のアクセス頻度なのだが。
Chromeユーザーはアドレスバーに↓コピペして確認してみてくれ。
chrome://settings/content/all?searchSubpage=tbs.co.jp&search=cookie
試しにCookie消去してから、ただ開いただけでサイト上で何の遷移もしてないのに279MBも保存された。
次点ではpresident.jpが553MB消費してた。(こっちも話題に挙がってたら見てみることもある程度。)
(その次にはGoogleが数百MBオーダーで消費してたけど、これはGoogleドライブのオフラインキャッシュとか考えれば妥当。他に数百MBオーダーで消費してるサイトは無かった。)
多くのサイトは数バイト～KBオーダーなのに、こいつら何保存してんのか不気味すぎる。
(追記)
各自の環境の消費量を教えてくれた方々や有意義なコメントを下さった方々ありがとうございます。
始めにお断りしておくべきだったかもしれませんが、自分はソフトウェア系ではありますが、Webエンジニアではありません。認識が浅かったり、古かったり、そもそも間違ってる可能性もあります。
CookieじゃなくてCacheStorageやんけと突っ込みもいただいていますが、「LocalStorageとかも含むのか知らんけど」と書いておいた意図は(どのような技術要素かはどうでもよくて)ユーザー端末に保存されるデータボリュームについての話を意図しています。ChromeのCookie絡みの設定画面での表示なのでこのような書き方をしましたが、解り難かったのならごめんなさいね。冗長ながらも認識齟齬を招かないように平易な表現で書くと、「ユーザの明示的な承諾なくユーザー端末に保存されるデータがデカイんだが」って話です。
で、各自の環境で「ユーザの明示的な承諾なくユーザー端末に保存されるデータ」が数GBオーダーにも及ぶという事例が少なからず報告されて、自分の環境だけではない事象だということが判りました。
さらにtbsとpresident以外にもいくつかのサイトが同様に肥大化していることも知れました。
結果的にはid:hinaloeさんの解説が解りやすかったです。ありがとうございます。
https://blog.hinaloe.net/2023/04/27/chrome-too-large-cache-storage/
CacheStorageがChromeの表示と、実際のディスク消費量と一致していないことが原因であると理解しました。
追試してみたところ私の環境ではChromeの開発者ツールでの表示が74MBで実際のWindowsのファイルシステム上は33.9MB消費されました。
実際のストレージの消費は表示値の半分程度ということになり、id:hinaloeさんの1.4GBに対して5MBのように実際の約0.3%という結果とは大きく乖離がありますので、各環境で大きく違いそうな気がします。
%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Service Worker\CacheStorage
※配下のどのディレクトリが対象サイトのものなのか一意に特定する情報が無さそうなので、Chrome開発者ツールのApplicationタブの左上の方にあるService Workersを選択すると、右側にReceived YYYY/M/D HH:MM:SSみたいな表記が有るので当該時刻に変更されたタイムスタンプを持つディレクトリを特定するような感じになるかと思います。
ついでに開発者ツールを触っていて気付いたベースで書いておくと、
といった感じで、ユーザが見たものをキャッシュしているのではなくて、先読みしてるような挙動に思えます。
ロード時間短縮でUX改善を狙ったものかもしれませんが、個人的にはそれを1か月も保持し続けるのは過剰な感じがしますが世の中的にはどうなんでしょうね？
(追記2)
hinaloe氏の投稿で紹介されているStackOverflowの投稿やそのリンク先のChromiumのバグレポートのやり取りまで目を通してみると、特に理由の説明なく平均7MBがパディングされると書かれた投稿があります。
https://stackoverflow.com/questions/39109789/what-limitations-apply-to-opaque-responses
https://bugs.chromium.org/p/chromium/issues/detail?id=796060
該当するソースコードは↓のようです。
この中で、ComputeRandomResponsePadding()という関数を呼び出しておりその実体は↓のようです。
この関数は符号無し64bit整数の乱数(つまり、0～18446744073709551615のいずれか)を14431 * 1024 = 14777344で割った剰余(つまり、0～14777343≒約14MiB)を返却します。
これがパディング値として採用されることになりますが、乱数が正規分布している前提で、平均すると(最大値14MiBの半分で)約7MBになるよねってことだと思われます。
故にChromeの設定画面から確認できるCookie等(LocalStorageとかCacheStorageとか諸々含む)のサイズは、概算してCacheStorageに存在するファイル数×平均7MBが過大計上されていることになりそうです。
これでChromeの設定画面から確認できるサイズと、実際のファイルシステム上で消費されているサイズの違いは合理的に説明できますが、TBS等の特定のサイトだけデカくみえる理由の説明にはならないのです。
なんなんすかね？
DMM版ウマ娘プリティーダービーを遊ぼうとしても、エラーダイアログを出さずに起動しなくなる現象に遭遇した。
Windowsのイベントビューアーを除くと、こんなログが吐かれていた（各IDは削除）。
=====
日付:
ユーザー:
説明:
障害が発生しているアプリケーション名: umamusume.exe、バージョン: 2020.3.24.51085、タイム スタンプ: 0x
障害が発生しているモジュール名: apphelp.dll、バージョン: 10.0.22621.963、タイム スタンプ: 0x
障害が発生しているアプリケーション パス: D:\DMMGames\Umamusume\umamusume.exe
障害が発生しているモジュール パス: C:\WINDOWS\SYSTEM32\apphelp.dll
結論から言うと、Windows本体のapphelp.dllが原因でウマ娘が起動できなくなっているという。
アプリケーションに罪は無いため、DMM Game Playerやウマ娘を何度再インストールしても直らない厄介な現象だ。
Windowsは数十万のファイルが存在するため、今回のようにWindows Updateやアプリケーションのインストール・アンインストールを繰り返すだけでシステムファイルが壊れる事がある。
Windowsでは、これを直すためのコマンドがコンソールUIのみに用意されている。
Windowsのスタートメニューを右クリックして、コマンドプロンプトまたはターミナルを管理者権限で起動する。
を実行する。これは、オンライン上にある正しいWindowsのシステムイメージを元に、壊れたファイルを修復する操作となる。
実行するとこう表示される。
[==========================100.0%==========================] 復元操作は正常に完了しました。
DISM.exeを実行すると、正しいWindowsのシステムイメージがPC内に保存された状態になる。
この状態で、
sfc /scannow
を実行すると、次のように表示される。
システム スキャンを開始しています。これにはしばらく時間がかかります。
Windows リソース保護により、破損したファイルが見つかりましたが、それらは正常に修復されました。
オンライン修復の場合、詳細は次の場所にある CBS ログ ファイルに含まれています
windir\ Logs\CBS\CBS.log (たとえば C:\Windows\Logs\CBS\CBS.log)。オフライン修復の場合、
これで、とりあえずWindows自体の修復コマンドによってシステムファイルが正しい状態に復元された状態となる。
実行してもまだメモリ上には古いシステムファイルが読み込まれて実行されている状態なので、終わったらPCを再起動する。
さて、準備は完了だ。ここまでの操作でWindowsを回復しDMM Game Playerで「ダウンロード版をプレイ」を押す事でウマ娘が起動し…ない！
イベントビューアーには今もウマ娘を起動しようとする度にアプリケーションクラッシュイベントが追加されている。救いは無いのですか？
結局、今回のケースではPCで常駐していたリモートデスクトップ用のSplashtop StreamerとVirtual Desktop Streamerをタスクキルする事でウマ娘が起動できるようになり、DMMブラックフライデーで得た有償石でおはガチャを回すことに23時成功した。
Application.GetOpenFilename()の戻り値がVariantの配列なのであれば、for文は0から始めるべきなんじゃね？
VBAはインデックスまわりややこしかった気がするから自信ないけど
あとは他の増田が言ってるように、配列の要素数が10とは限らないのであれば、配列の要素数（1始まりの場合）か配列の要素数-1（0始まりの場合）をfor文イテレータhの最後の数として指定するべき
Sub test3()
Dim ws1 as Worksheet
Dim ws2 as Worksheet
Dim Filename as Variant
Dim h as Long
Filename = Application.GetOpenFilename("xlsmファイル,.xlsm", Multiselect := True)
For h = 1 to 10
Workbooks.open(Filename(h))
Set ws1=Workbooks(Filename(h)).Worksheets(1)
Set ws2= Workbooks("excel勉強用.xlsm").Worksheets("Sheet1")
Workbooks(Filename(h)).close
next h
End Sub
これでインデックスが有効範囲内にありませんのエラーが出ちゃう。(Set ws1 = Workbooks(Filename(h)).Worksheets(1)のところ)
Workbooks.open(filename(h))でファイルを開くこと自体は確認できた。
GetOpenFilenameをそもそもあんまよくわかってないのに使ってるのが問題ですかね？
例えば020101.xlsx,020102.xlsx,020103.xlsx....020110.xlsxという10個のブックをGetOpenfilenameメソッド(?)で選択したとしたら、
変数Filenameには上記10の配列が入っていて、Filename(1)で020101.xlsxを呼び出すことができるのかな〜って思ったけど違うっすかね？
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。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の登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。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の登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
多くの方がご存知の通り、Log4j 2 (以下面倒なので Log4j) の脆弱性 CVE-2021-44228 が公開されて一週間が経過しようとしています。
ちなみに、数時間前に修正不備として CVE-2021-45046 が出ています。formatMsgNoLookups による対策はできません。大変ですね。皆さん対応のほう、いかがでしょうか。
自組織で Java アプリケーションを開発している場合は、把握しやすいかもしれません。ですが、Elasticsearch や Apache SOLR などのソフトウェアなど、インフラ基盤として利用しているソフトウェアへの影響を確かめるのはなかなか大変な作業だったのではないでしょうか(もちろん素早くアナウンスを出してくれたところもありますが、ゼロデイだったこと、US は夜であったことから、アナウンスを待つ前に対応が必要だったところもあると思います)。
OSS なら依存パッケージを比較的調べやすいですが、Splunk や Salesforce のようなアプライアンス製品などはどうでしょう。スイッチやルーターは? クライアントの Java アプリケーションもですね。さらに、業務委託先はどうでしょう。考えることが山積みです。
ソフトウェアサプライチェーン管理の難しさを痛感した組織も多いのではないかと思います。
ゼロデイだったため、最初は対策方法についてもまとまっておらず、間違った対策方法が流布しているのも見かけました。
「特定のクラスファイルを削除する」という正しい対策も、「えっ マジかよ。クラスファイル消して他に影響でないのかよ。それはないだろ。」と思った人もいると思います。私は思いました。なんだその対策。
その他 Web Application Firewall のバイパスなど、ご対応された皆さん、本当に大変だったと思います。お疲れ様です。
これも全部 Wizard Bible 事件やアラートループ事件の影響なんだろうけど、それにしても具体的な攻撃手法が共有されてなさすぎだろ。
最初てっきり LDAP 閉じたり、WAF で jndi:ldap を弾けばいいと思ってたよ。対象を把握して全部対応するの大変だから、まずはそれでいこうと思ってたよ。全然ダメじゃん。RMI とかいうよく分からないパターンもあるし、${lower} とか使って WAF バイパスするとかしらねーよ。そんなのできんのかよ。
攻撃のメカニズムなどを解説してくれている記事があれば、最初から迷わず頑張ってアップデートする方向に舵取れたと思う。
誰も情報共有しないとセキュリティ業界衰退しますよ。人材育成もできないし。サイバー人材育成不足とか言う前に、ちゃんと然るべきところに意見言いましょうよ。
小学校で配られた端末のセキュリティ突破が話題というのもニュースで見たし、放っておくと規制の方向にエスカレートしてしまうと思いますよ。
そういえば情報共有でいうと CISA は動きが素早かった。最初は個人の gist に影響のあるソフトウェアがまとめられていたけど、数日後には https://github.com/cisagov/log4j-affected-db で網羅され始めた。Pull Request も取り込んでいて、素晴らしい。
一方で JVN DB の方はどうでしょう。https://jvn.jp/vu/JVNVU96768815/
報告を受けている製品しか書いていないのですかね。国内製品はもっと影響あると思うし、公表している製品もあると思うんですが。積極的にまとめていかないんですかね。こんな状態だと、組織は影響範囲を調べるのに苦労しますよ。
「セキュリティ業界このままじゃダメだと思うのですが、なにか動きはあるんですか？」「皆さん利用している製品やソフトウェアの把握どうされているんですか? 」の2点をお聞きしたかったのです。
Chrome/Firefoxのはてブ機能拡張は配布されているが、Mac版Safariの機能拡張は数年前から配布されていない。
Safariに乗り換える際の個人的な障壁であったが、Chrome版機能拡張をSafari向けに変換して利用する事ができたので、メモ代わりに記しておく。
1. Chromeのアドレスバーに「chrome://extensions/」と打ち込み、機能拡張の画面を表示する。
3. 同画面内の「はてなブックマーク」の欄に表示されている「ID：xxxxxx」を次手順で使用する。
4. FinderでChromeのはてブ機能拡張がインストールされているフォルダが存在する事を確認する。
/Users/(ユーザー名)/Library/Application Support/Google/Chrome/Default/Extensions/(手順3のID名)/(バージョン番号)
5. ターミナルを起動して、以下コマンドを入力後にReturnキーを押す。この際に「Is this correct?」と表示されたら「yes」と入力後にReturnキーを押す。
6. XCodeが起動されるので［▶］ボタンを押して、Safari向け機能拡張をビルドする。（ビルド後に起動されたアプリは終了して良い）
7. Safariを起動して、「開発」＞「未署名の機能拡張を許可」を押す。（「開発」メニューは、「Safari」＞「環境設定」＞「詳細」＞「メニューバーに“開発”メニューを表示」で表示される）
8.「Safari」＞「環境設定」 ＞ 「機能拡張」にてはてブ機能拡張のチェックを入れ有効化する。
9. Safariのアドレスバーの横にはてブのアイコンが表示されていればインストール完了。
1. はてブのアイコンに [▲] のアラートが表示されている場合、アイコンを押して「すべてのWebサイトで常に許可」を選択する。
2. はてブのアイコンを押すと表示される利用規約画面で「同意する」を押す。（なお「同意する」を押しても何もリアクションがないので、手動でタブを閉じる必要がある）
3. はてブのアイコンを押して見慣れたはてブコメント一覧が表示されていれば設定完了。
上記手順では基本的にSafariを再起動する度に「未署名の機能拡張を許可」を行ってはてブ機能拡張を有効化する必要がある。
メニューから選択するだけの手間であるが、頻繁にSafari/Macを再起動するので面倒という場合には以下手順にて機能拡張に署名を行っておく。
1. 上述したインストール手順の「手順6」にてXCodeが開いている状態で画面内サイドメニューから「はてなブックマーク」を選び、画面中央上部の「Signing ＆ Capabilities 」タブを押す。
2.「Signing」＞「Team」で自身のApple IDを選択する。（選択リスト内に存在しなければ「Add an Account…」でアカウント追加後に選択する）
3.「Signing」＞「Signing Certificate」で「Developement」を選択する。
4. 手順2-3を「Target」の「はてなブックマーク」と「はてなブックマーク Extension」の両方で実施後、［▶］ボタンを押して、Safari向け機能拡張をビルドする。
5. Safariにて「開発」＞「未署名の機能拡張を許可」を外した状態でもはてブ機能拡張が表示されていれば完了。
「共通言語たるドメインモデルを、そのままコードと1対1対応しなければならない、という思い込みや風潮。
既存のWAF(Web Application Framework) の利点を潰してどうする…」
こういう誤った思い込みをエンジニアにさせているのは、ドメイン駆動設計の原典である「エリック・エヴァンスのドメイン駆動設計」が、いかに抽象的な内容で、ある意味では哲学的であったかを、明示するものでは無いか。
プログラムとはメタファーであり、現実を、もしくはそれに準ずる写像的な世界観を、コードに忠実に再現するものでは必ずしも無いと考える。この記事の増田は「過度な抽象化」とも書いているが、プログラムというか、そもそも言語そのものが物事の全てを表象できるものではなく、ある一側面の一イメージしか切り取れない不完全なものだし、それ自体が問題ではない。現実とソフトウェアの溝を、ユーザーとエンジニアの溝を、ドメインとソースコードの溝を、いかにして埋めるかというのが、ドメイン駆動設計の本質だし、その埋め方についてはエリックエバンスは一例を示しているに過ぎない。EntityやValueObjectなど、必要なら使えば良いし、不要なら使わなければ良いのだ。ただし、元々何が問題なのか、問題だったのかという点について、いかにして向き合うかが肝要であり、それは技術論や方法論の話ではない。
ドメイン駆動設計の記事を書いたり、勉強会で発表をしている人間は、原典やそれに付随するドキュメントの内容を、無批判に信奉し、そのようにしなければならないという強迫観念に追われているのではないか。そもそも、本当に理解しているか怪しいし、不安だから教科書の内容にしがみつこうとするのだろう。さらにこの手の連中は、昨今のCQRSやイベントソーシングやマイクロサービスなどとも絡めて話をし出すから、タチが悪い。「ドメイン駆動設計はこの手の技術スタックと相性が良い」という言葉を何度も見かけたが、技術的な方法論はそもそも無関係だったはずだし、そうやって安易に結びつけてしまうから、ユーザーが置き去りになって来たんじゃねーのと、暴言でも吐きたくなる。問題の本質はどこにあったのかを、聖典の内容や、流行り廃りの技術とは切り離して、エンジニアは三思九思すべきだ。
別にこうあらなければならないという法律や決まりは無いし、好きにやれば良い。モデルと1対1にならなければ、分割する事を選択するのも一つの向き合い方だ。ドメイン駆動設計の信者ににゃんにゃん写真でも撮られて、ばら撒くと脅迫されているのであれば勿論話は別だ。恥ずかしい写真を魚拓されたくなければ、とりあえずEntity、ValueObject、Repository、Service（笑）位は最低限、用意するのが身のためだろう。
自分の頭で考えて、自分の責任で判断するという当たり前の事に立ち返りたいものだ。ドメイン駆動設計という盲目的な宗教からいかにして抜け出すかが今後のエンジニアの課題だろう。
追伸
% poetry cache clear --help USAGE poetry cache clear [--all] <cache> ARGUMENTS <cache> The name of the cache to clear. OPTIONS --all Clear all entries in the cache. GLOBAL OPTIONS -h (--help) Display this help message -q (--quiet) Do not output any message -v (--verbose) Increase the verbosity of messages: "-v" for normal output, "-vv" for more verbose output and "-vvv" for debug -V (--version) Display this application version --ansi Force ANSI output --no-ansi Disable ANSI output -n (--no-interaction) Do not ask any interactive question
これ見ると
poetry cache clear pypi
で動きそうじゃん？
% poetry cache clear pypi RuntimeError Add the --all option if you want to clear all pypi caches at /usr/local/lib/python3.8/site-packages/poetry/console/commands/cache/clear.py:44 in handle 40│ ) 41│ 42│ if len(parts) == 1: 43│ if not self.option("all"): → 44│ raise RuntimeError( 45│ "Add the --all option if you want to clear all " 46│ "{} caches".format(parts[0]) 47│ ) 48│
ブブー
動きません
正しくはこう
poetry cache clear pypi --all
直感的には--allをついてたら全てのキャッシュを消すべきだと思うが
% poetry cache clear --all Not enough arguments (missing: "cache").
ブブー
動きません
意味不明に思ったのは俺だけではないらしくIssueが出ている
https://github.com/python-poetry/poetry/issues/521
opened this issue on 19 Oct 2018 · 18 comments
2年前ですよ2年前!
Issue700個も溜まってますよ
pipenvもアレだったけどpoetryもアレだな
もう少しマシな奴が欲しい
「QAに聞いたんですけど、あのバグ、やっぱまだ直ってませんでした。だから、狙う時は“ここ”をお願いします」
「五代……」
「いやもちろん、万が一、俺が“究極の闇をもたらす存在”になっちゃったらですけどね」
「……。こんな寄り道はさせたくなかった」
「え？」
「……」
「ここまで君を付き合わせてしまって……」
「ありがとうございました」
「……？」
「五代……」
「じゃあ、見てて下さい。俺の――変身」
＞＞ java.lang.NoSuchMethodException: com.laurens.Main.main([Ljava.lang.String;)
at java.lang.Class.getMethod(Class.java:1786)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:125)
