はてなキーワード: リポジトリとは
したがって、ネットワークにアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である。
Git(ギット[2][3][4])は、プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システムである。Linuxカーネルのソースコード管理に用いるためにリーナス・トーバルズによって開発され、それ以降ほかの多くのプロジェクトで採用されている。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が置かれている。現在のメンテナは濱野純 (英語: Junio C Hamano) で、2005年7月から担当している。
Gitでは、各ユーザのワーキングディレクトリに、全履歴を含んだリポジトリの完全な複製が作られる。したがって、ネットワークにアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である。
弊社ではその設立当初、というよりも創業者(=私)が個人事業主だった頃から業務にFLOSSを多用しています。
今回その事例を情報共有するためにエントリを作成いたしました。
従業員50人ほど(学生アルバイト含む)の会社です。ちなみにかなりボカして書きます。
弊社では社内文書をSDGsの観点からペーパーレスに努めており……と表現すると些か格好付けすぎなので正直に言えば個人事業主時代に印刷機複合機のランニングコストがバカにならなかったので物理ペーパーへ出力するのを控えていた運用がそのまま法人化されても続いているだけです。
社内文書として用いられる文書フォーマットはODF形式で統一している……というかコレもまた個人事業主時代にOpenOfficeを活用しており、現在社内で使われている主なオフィススイートはLibreOfficeとなっています。
注意点としては弊社がルールとして定めているのはODFを用いることでありLibreOfficeの利用を強制しているわけではないという点です。
従業員の中にはLibreOfficeを常用せず、AbiWordやGnumericを普段使いしている者も居ます。
弊社は社外とオフィス文書ファイルをやり取りすることが一切なく、オフィス文書ファイルと表現するには正しくないですが社外とはPDFをやり取りするくらいなので何か問題が起きたことが今まで特にないです。
ただ1つ問題があり、弊社はこれまでLibreOfficeを無償で活用させて頂いており、これまでの感謝を示すためLibreOffice Enterpriseへの移行を考えているものの日本国内でLibreOffice Enterpriseを利用するための情報が一切なく困り果てています。
最悪、海外の企業を頼る方法もありますがサポート時間の都合などがあるため可能ならば国内で探したいと考えています。どうにかならないものですかね?
社内では「むしろウチがやったら?」なんて声もチラホラ聞こえますが……。
ちなみに社内デファクトスタンダードのフォントはNoto Sans Japaneseです。一部でTakao(IPA)が使われています。
弊社ではFLOSSを活用しているせいもあって特にOSの縛りを設けていません。何なら経理担当はChromebook使ってます。
社内のOSシェアはChromeOSを含めたLinuxディストリビューションが5割、macOSが2割、残りがWindowsとその他です。
気になるであろう開発環境についてですが、Dockerを用いて開発環境の統一化を計っており、その時々に応じてDockerコンテナを切り替えて開発しています。
Dockerを用いているせいもありLinuxディストリビューションの社内OSシェアが高くなっているのです。
プライベートで従業員は様々なOSを選択しているようです。ゲームとかVRが趣味であるならばWindowsしか選択肢ないでしょうしね。
ちなみに業務用のPCはBYODで購入補助あります。
結局は従業員の現物給与として課税されてしまうだけなので「いくらでも良いけど高すぎるの買うと年収増えすぎて痛い目みるよ?」とは助言してます。
会社はまとまったお金を出しているに過ぎないのでメリットとデメリットがありますよね。
いちいち申請出す方もチェックする方も面倒なのでGNUプロジェクト下ソフトウェアは無申請で利用可としています。
ただし制限は公式リポジトリまたは弊社が安全だと判断しているリポジトリで配布しているバイナリのみという条件が付きます。
どこの会社もそうでしょうけれどもAWSやAzure、GCPなどたいてい大手に置いてますね、予算の都合もあるけれど。
これは弊社が強制しているわけではなく、弊社デザイナーの第1号従業員がWindowsユーザであったので惰性のままWindowsとなっているだけであり、中にはMacで仕事している従業員も居ますし、状況によってLinuxディストリビューション(主にUbuntu)上で仕事しているときもあります。
Linux環境では苦手なIllustratorのAI形式などはSVGやラスター画像に落とし込んでもらって開発者が適用するという運用になっています。
社内では特定の環境へ依存するファイル形式はとことん嫌われる傾向にあります(妙な仕事が増えるから)。
開発者から経理、デザイナーに至るまで弊社従業員はみんなGitが使えます。
ただし使えると言っても全員がCLIからコマンドを打てるわけでなくGUIクライアント上からの操作しか出来ない者も居ます。
主に使われているGitのGUIクライアントはGitKrakenです。
入社時の受け入れ教育でLibreOfficeやGitの指導をすることになっており、全従業員が浅くともGitとは何ぞや?を理解している状態にあります。
ちなみにGitリポジトリは主にGitLabへ置いていてUltimateを契約させてもらってます。
社内にセルフホストしているGitLabサーバもありますが、こっちは従業員が個人開発しているものを投げているようですね。業務にあまり使われていません。緊急時のバックアップと思われるものがちょこちょこありますが。
プロジェクト管理ツールはいろいろと試したのですがOpenProjectへ落ち着きつつあります。
プロジェクト管理ツールの選定は各プロジェクトマネージャへ任せているのですが、旧来からあるRedmineと操作性が近い上にGitLabとの連携も容易でなかなか良いとのこと。
他社とのやり取りにSlackやTeamsやZoomが出てくることもありますが、社内だけで完結する際はたいていElementが使われています。
これは当時インターン生だった弊社の現従業員が若者の熱意と共に持ち込み、サーバを与えたら喜々として運用をはじめたので、それをきっかけに便利だったからそのまま使わせてもらってます。
ぶっちゃけて言えば私個人のこだわりはチャットにありません。従業員が楽しそうに使っていればそれで良いんじゃないかと。
IRCとか持ち出されたら「今どきそれはどうなの・・・まぁ良いけど」って言うかも知れませんが。
会計はFreeeです。特にこだわりはありません。たまたまWebブラウザから使えたのでFreeeとなってます。
残り5%は主に私が出社しているからw
社内にサーバがあるので私以外も出社してくることはありますが基本的にコロナ禍以降は全従業員がリモートワークです。
そもそもコロナ禍以前でもリモートワークしてた気がしなくもないのですが当時は3割4割くらいだったでしょうかね?週に何度か出社して来ないが自宅からdoneしてくる従業員が何名も居たので。
タイムカードもElementのbotへ投げると自動的に処理するようになってます……が、実際のところ最後の処理で私が大目に時間を付けてます。打刻を忘れることもあるしね。少ないより良いやろw
結局、郵送物(今ならコロナワクチン関連とか)を処理する必要があったりなど誰かしら会社に人が居なければならず、自分でも忘れがちですが創業者なので私が会社に居るよってことで私だけがほぼ出社するという状況になってます。
オフィスの処分も一時期考えたのですが、増員への教育とか考えるとやっぱりオフィスあったほうが良いよなぁなんて思ってそのままです。もしかしたら引っ越しするかも?
1つだけ申し訳ないことがあって、コロナ禍の状況下でどうやって増員したら良いのか教育したら良いのか私の能力を超えていまして現在は新規募集を停止中です。いやホント申し訳ない。
事業が軌道に乗った以降は毎年最低1人は取ろうねと古株と話していたんですが、こうなっては無理だよねと苦笑しあってます。
どうやって世間の同規模中小企業は新人教育やってるのか解らなすぎる。会社に誰も居ないじゃんと。
上場する気も更々ないし無借金なので、のん気にこのままゆっくりと会社を維持していきたいなぁと思ってます。
早くコロナ禍終わらんかなぁ……。
ならないんだよなあ。
そもそも数学とプログラミングはモチベーションが違うんだよね。数学における証明に構成的証明と非構成的証明があるように、「手続き」というのは数学のごく一部でしかない。それに対して、プログラミングは「手続き」が全てだよね(って言うと関数型とかの人があれこれ言ってくるけど、関数型言語だって結局コンパイラが手続きに落とせる範囲のものでしかない)。
機械学習については、論文書いてる奴も含めて大多数はプログラミング脳なので、最初からコードで発想してそれを論文にするために無理矢理数式で書いてるだけというものがほとんど。無理矢理書いた後付けに過ぎないから意味不明なものも多いしコードに落とせないものも普通にある。だから数式は無視して著者のリポジトリにあるコードだけ見てればいいよ。実用の観点ではコード公開されてない論文は全無視で何も問題ない。
Nix はいいぞ。
#!/usr/bin/env nix-shell
...っていうのができる。
上記の例の "zsh" を、"make -f" とかすると Makefile になるし、リポジトリ nixpkgs に含まれるファイルを渡す式のコマンドなら何でも使える。実行ファイルにしたスクリプトを走らせると、その場でインストールされてないツールをインストールしてくれる。
ささっと書いたカジュアルなスクリプトでも、将来、環境が変わっても使えてると嬉しい。本格的なプロジェクトを作ってパッケージマネージャのリポジトリに登録するつもりはない、そんな場合に Nix のシェバン機能は役に立つ。
Nix 言語を使うと、かなり柔軟にインストールの方法を作りこめる。シェバン機能を覚えておくだけでも効果が高いから、おすすめだよ。
文脈がよく分からないので、他での指摘と重複していると思うが、個人的に思ったこと。
文章がMECEでないので「まあそういうことね」という話は措いておいて。
a. 日本語ウェブサイトの記事本数で比較することはフェアではない
新しめの技術を活用している人の情報収集の順番としては、エディタでライブラリの当該部分のソースコードを読む、GitHubにリポジトリがあるのであれば、そこのissuesで検索をかける、Googleで英語(エラー文言等なので必然的に英語になる)で検索する、Stack Overflowで質問するという感じだと思うので、Qiitaでの出現数が減ることは仕方ないと思う。
ミクロで見ると、フロントエンド系の主要な論客がQiitaから離脱していることもある。
SSGの登場によってSPAのネガな部分のほとんどは潰されていると思う。
SPA的な手法を使うのであれば、SSGにしろという指摘であれば、的を射ていると思う。
他にも色々と言いたいことはあるが「SPAのことを言ったら一斉に突っ込まれた」という事象を観測できないので、とりあえず以上。
恋愛経験の有無3群で比較したところ,有意には至らなかったが(χ2=4.01,df=2,p=.135),交際経験を有する者の約75%が,記録を伸ばしているし,いずれの群でも過半数以上が大学3年生以上で記録を伸ばしている.今回の調査対象者には競技レベルの差があることは否めないが,恋愛経験と成績向上には負の関連性はないし,恋愛の肯定的効果も示唆される.
交際期間の長さ3群で比較した.対象は恋愛経験のある49名である.χ2検定の結果,5%水準で有意差が認められ(χ2=6.38,df=2,p=.041),長期間交際群の約8割は記録を向上させている.中期間では向上,低下が半数となっている.短期群13名でも記録低下させていた者は1名のみである.長期にわたる特定相手との交際のみならず,短い期間であっても,記録の向上とは関係なく,長期間の安定した恋愛経験は記録の向上に寄与することも考えられる.
我々のデータからは,大学運動選手の恋愛は競技のマイナス要因ではなく,競技生活を充実させるプラスの要因になると言える.本論の副著者は,在学中も全日本のトップレベルの女性アスリートで4年生次に最高成績を収めている.彼女自身,学生時代の恋愛には肯定的であったし,「あくまでも競技生活が第一優先事項という前提が不可欠で,恋愛関係と競技生活の優先度が逆転してしまうと、やはり競技生活に悪影響を及ぼしかねなかった」と回想している.
神戸大学学術成果リポジトリKernel http://www.lib.kobe-u.ac.jp/kernel/seika/cover/ISSN=21868719.html
棒が伸びると記録も伸びる (至言)。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
361あとで/3270users 逮捕にそなえる人生継続計画 - やしお
257あとで/1505users 筑波大教授が著した無料の初心者向けPython教材「とてもわかりやすい」「素晴らしすぎる」 | Ledge.ai
246あとで/1545users 【独学可能】英語を話す方法 第二言語習得研究と行動科学に基づく英語学習ロードマップ - ポリグロットライフ | 言語まなび∞ラボ
228あとで/1502users 「1Byteが8bitに決まったワケ」についての長い話 まずは「バベッジの階差機関」から | ITMedia
228あとで/1340users 1on1 ノウハウの共有 | DevelopersIO
218あとで/2069users 音声合成業界に激震! もはや人間の喋り声、入力文字読み上げソフトVOICEPEAKはビジネス用途でも自由に利用可能|藤本健の “DTMステーション”
172あとで/1057users 2022年ウクライナ情勢をより深く理解するための歴史文化背景雑学|tadhara|note
170あとで/912users BIOSからUEFIへ BIOSはなぜ終わらなければならなかったのか | ITMedia
168あとで/1175users 早く寝るために自分自身をハックする - 本しゃぶり
160あとで/1187users 富士通の撤退する「メインフレーム」ってそもそも何? | koduki | Zenn
152あとで/854users 「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか | 櫛田 瑞穂 | SpeakerDeck
148あとで/1128users 【登大遊】天才エンジニアの安寧を求めない生き方「日本で“大義”を持って働く選択は有利」 - エンジニアtype | 転職type
146あとで/1624users 元葬儀屋のワイが神奈川県警の悪事を淡々と話すスレ : うしみつ-5chまとめ- #神奈川
143あとで/756users 事業開発者・プロダクトマネージャーが知っておくべきフレームワーク7選|Shin|note
142あとで/1250users 「Google検索は死んでいる」がバズったので「まとも検索」を作った。:村上福之の「ネットとケータイと俺様」:オルタナティブ・ブログ
138あとで/728users OSS未経験「なにから始めたらいいかわからない…」←これを一気に解決する神リポジトリ - Qiita
137あとで/1202users 中小企業でApple製品を利用する前にやっておくこと | Hiroshiman | Zenn
128あとで/1357users 1分でわかるウクライナの歴史 | anond.hatelabo.jp
124あとで/1265users 【Mac】Kindle本も永久保存!自動スクショでPDF化する方法|脱凡リーマンブログ
124あとで/1192users これだけは押さえよう!住所フォームの作り方 - ケンオールブログ
119あとで/928users 今のウクライナ情勢が分かりやすくなる…地政学漫画『紛争でしたら八田まで』が凄いと話題 | Togetter
118あとで/875users 「詩」というもの/谷川俊太郎|「新潮」編集部|note
118あとで/955users 子どもの自己肯定感を下げるNG言動 5000人を育成してわかった低い子の特徴(みらのび) - Yahoo!ニュース
115あとで/1012users 人は「楽と感じる方法」しか選ばないことを前提に、仕組みを作らなければならない。 | 桃野泰徳 | Books & Apps
112あとで/1044users 定年退職後に料理をはじめた父の「大葉漬け」がヤミツキ必至の美味しさでご飯がとまらない/ 大葉の大量消費にもオススメ! | 砂子間正貫 | RocketNews24
112あとで/760users 東京都デジタル人材確保・育成基本方針 ver.1.0 | 東京都 | SpeakerDeck
111あとで/631users ソフトウェアアーキテクチャの基礎 | O'Reilly Japan
108あとで/652users ブラウザで動くサービスを作るときの技術選定 | moga | Zenn
105あとで/755users 2024年に制度変更「つみたてNISA」 始めるなら2022年が有利な理由 | マネーポストWEB
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【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から見ると単に1つのプロセスが稼働している扱いになる。
【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%増加する、という任意のステップに従ってタスク数を増減させる
なんかの機能追加というタスクがあるとまずタスクを分割してTODOアプリに登録する
こんな感じ。できる限り1タスク1~5分くらいで終わる量に分割する
1メソッドが大きい場合は例外処理のみ、DB登録部分のみ、メール送信部分のみとかそれだけでもタスクを分ける。
30秒で終わるようなことでもタスクとして独立してたら分けて登録する
「30分あれば上から12個こなせるな」とか見積もりして該当タスクに印をつけて30分タイマーで都度タイムアタックする
タイムアタックが終わると5分ほど休憩。見積もってた分が30分より早く終わってもその時点で休憩。5分くらい?
Youtube見たり在宅だったらえっちぃビデオ見たり音楽聞いたり好きなことをする。
終わったらまた30分分のタスクを見繕ってタイムアタック。それの繰り返し
ちなみにSlackで問い合わせとか来た場合はその時点で返信より前にTODOとして登録。何故ならそうしないと絶対返信忘れるから。