  |
はてなキーワード: 一般公開とは
何やったのか当時の反応を含め記憶が曖昧なので内閣支持率を元にトピックスを書きだした。
前月と比較して7%以上内閣支持率の増減があったときのみ書き出した。
最初は5%増減で書こうとしたけど時事を調べるのが面倒で無理だった。
トピックス以外の雰囲気を掴む為、次のようなものも合わせて記す。(適当に作った)
内閣支持率の出典
【オレオレFC】サポーター約300人が見学 相田監督「大きな一歩」18日清水戦へ
オレオレFCは16日、18日のホーム・清水エスパルス戦に向けて調整した。この日は抽選に当選したクラブサポーター約300人が練習を見学し、選手らに熱い視線と拍手を送った。相田満博監督は、さらに激しさを増すリーグ戦を勝ち抜くため「向上」と「トライ」をテーマに掲げた。
◇ ◇ ◇
新型コロナウイルス感染拡大防止のため、20年2月25日から自粛していた練習の一般公開をこの日限定で行った。選手たちはクラブハウス隣接ピッチに集まったサポーターの前で久しぶりに汗を流した。相田監督はオンライン取材で「大きな一歩ですね。選手達も待ち望んでいたでしょうし、いい雰囲気の中で練習ができたと思います」と感慨深げに振り返った。
今季、コーチ経験もない中で監督に就任。初のプロ監督業に不安の声もあったが、多彩な戦術と多くの選手を大胆に起用し、チームの総合力を高めている。リーグ戦序盤は開幕6戦未勝利（3分け3敗）と厳しい船出となったが徐々に調子を上げ、現在、リーグ戦10試合負けなしと好調。それでも「負けたらズルズル行くときもある。目の前の1戦1戦が重要なので」と浮かれずに今後も戦う。
天皇杯3回戦を含め、ホーム4連戦の2戦目となる次戦は18日の清水戦だ。清水とは通算1勝3分2敗。アウェイでは1勝2分だが、ホームでは1分2敗と未勝利。昨年9月も敗れ、最終戦まで残留を争った。清水は5試合未勝利でゼ・リカルド新監督の就任初戦となるが、相田監督は「今以上のトライをして、我々のクオリティーを向上させ、そこを上回って勝ちに行きたいです」と力を込めた。
獲得が濃厚なDFリシャルソンと韓国のDF尹が16日に来日していたことが分かった。あすチームに合流して、18日の清水戦を観戦する予定で、近日中にも正式契約を結ぶ予定。
リシャルソンは完全、尹は期限付き移籍になる見通し。合流してから当面はJリーグの第2登録開始となる7月15日まで練習生として参加する見込み。
演奏不可能の作品（えんそうふかのうのさくひん）とは、さまざまな理由により演奏が不可能、あるいは困難な音楽作品のことである。
クラシック音楽の世界では、演奏が不可能（または困難）な作品が多数存在する。演奏不可能な作品の中にも、仮に演奏されたとすれば傑作と評価され得るだけの芸術性を備えた作品は多く、これらは安易に無視できない存在となっている。巨大編成の作品や演奏時間の長い曲とも密接に関係があり、イギリスのソラブジの作品はその3要素が完全に組み合わさり、初演できないものも多数ある。
現代のポピュラー音楽の場合には、作曲家、作詞家、編曲家といった独立した職能も存在するものの、作品は演奏との一体性が強く、コンサート、ライブでの生演奏や、演奏を収録した媒体（CD等）という形で公表される点で、クラシック音楽とは様相が大きく異なる。このため、ポピュラー音楽においては、作品を聞くことができるという意味で、ほぼ全ての作品が演奏可能であるといえる。その一方で、媒体への収録（すなわちレコーディング）に際しては多重録音をはじめとする種々の編集が行われるとともにに、演奏においてはシーケンサー等の自動演奏が積極的に利用されるので、純粋に人のみによって演奏することが不可能あるいは困難である作品も多い。このような作品をコンサートやライブにおいて生演奏する際には、自動演奏やテープなどを用いてレコーディングされた作品を再現するか、生演奏が可能なようにアレンジを変えることがよく行われる。また、一時期のXTCのように、高度なスタジオワークを行うミュージシャンの中にはライブを行わない者もいる。
歴史は長く、J.S.バッハの諸作品、モーツァルトのオペラフィガロの結婚や魔笛、ベートーヴェンのピアノソナタ第21番、第29番、ピアノ協奏曲第1番や交響曲第7番・第9番などが古典的な例とされる。
ロマン派では、ロッシーニの「セヴィリアの理髪師」の第19番のアリアは良く省略され、シューベルトの魔王や交響曲第9番「ザ・グレート」、パガニーニのヴァイオリン曲、ロベルト・シューマンの交響的練習曲の第2変奏曲や2点へ以上の音域がある4本のホルンとオーケルトラの為の協奏曲作品86、リストの一連のピアノ曲、ウィーン・フィルハーモニー管弦楽団に演奏不可能と宣告されたブルックナーの交響曲第2番、ブラームスのピアノ協奏曲第2番やヴァイオリン協奏曲またピアノソナタ第3番の冒頭部、チャイコフスキーの諸作品、マーラーの交響曲、ラフマニノフのピアノ協奏曲第3番等があったが、それらは現在では演奏技術の発達により演奏不可能と見なされることはなくなった。しかし、プッチーニの「ラ・ボエーム」第一幕のエンディンクは、未だに半音下げて歌われることが多い。
近代ではストラヴィンスキーの春の祭典、シェーンベルクのピアノ協奏曲やヴァイオリン協奏曲、モーゼとアロンがあるが、「春の祭典」と「モーゼとアロン」は演奏技術の発達により現在では演奏会での一般的な曲目になっている。意図的に作曲された例としてアイヴズの歌曲「義務」があるが、今日では演奏家は内声などを省略するか、アルペジオで演奏するか、アシスタントを設けるかで解決されている。彼のピアノソナタ第2番等も同様であるが、本人は「間違った記譜もすべて正しい記譜である」と友人に説明している。プロコフィエフのピアノ協奏曲第3番の第3楽章にも2度の音階的な走句があるが、「困難だ」と結論付けて全てアルペジオで演奏する者もいる。ラフマニノフのピアノ協奏曲第三番第三楽章の冒頭のパッセージは身長が170cmないと物理的に不可能であり、体格の小さなピアニストやテクニックに不自由したピアニストは左手の音をずらして演奏することが慣例化している。
演奏不可能の作品という概念は現代では新しい複雑性と深く関係している。ファーニホウの諸作品は非常に高度な演奏技術を要するが、彼の音楽に要される困難は主に読譜に集中するため決して不可能な音楽ではないとされる。しかし逆説的に言えば、演奏不可能の概念は、今日例えばパソコンのシーケンサーなどに自分で四分音符をメトロノームに合わせてキーボードで打ち込んでも決して4分音符や強弱が正しく出てこないという経験から、人間が演奏する限りにおいて全ての音楽に当てはまるという事も言える。その外シュトックハウゼンの「7つの日々からNr.26（1968）」の「金の塵」が奏者に演奏の前に4日間の断食を強要していると言う点で事実上の演奏不可能の作品である。
今日最も演奏の難しい現代音楽は、クセナキスの諸作品と言われている。第1曲目のピアノ協奏曲にあたる「シナファイ」、チェロ独奏の為の「ノモス・アルファ」、ピアノ独奏曲の「エヴリアリ」、「ヘルマ」、「ミスツ」、ピアノ独奏が重要な働きを担う「エオンタ」及び「パリンプセスト」等がその例である。クセナキス自身はテレビのインタビューで、これらは演奏困難にさせることを目的として作曲された作品であると語っている。
しかしこれらの作品群も、近年の若手演奏家の技術向上やCDリリースを参照する限り、徐々に不可能とは見なされなくなる日が近づいているのは確かであるが、逆にどんな簡単な作品も人間が演奏する限り100%の完全なる再現は厳密には不可能である。
前述の通りポピュラー音楽はクラシック音楽とは事情を異にする。とは言え、カバー曲やカラオケなど、オリジナル以外の奏者による演奏がまったくないわけではない。
特筆される例としてはサザンオールスターズの「Computer Children」（作詞・作曲 桑田佳祐。アルバムKAMAKURA収録）が挙げられる。この曲は、マスター収録の後にエフェクトなどのデジタル編集を行い、その編集後の曲がオリジナルとされている。したがって、ライブ演奏は事実上不可能となっている。ソフトウェア用マスター作成においてデジタル編集を行うポピュラー音楽は近年珍しくはないが、この曲ほど大胆に使用している例は（リミックスを除けば）、稀有である。
作曲家が演奏困難な作品を書くことによって、演奏技術が向上し、それがさらに作曲技法を拡大させるいう面がある。以下の曲の多くのものは今日では演奏やレコーディングの機会も多いが、作曲当時は「演奏困難」ないし「演奏不可能」とされたものである。参考までに掲げる。
指定された速度で演奏するのはほぼ不可能であり、通常は指定よりもやや遅くして演奏される。また、曲が独奏曲にしては長大であるため、高度の精神力が要求されるという点においても彼のソナタの中では最も演奏困難である。演奏技術の発達した現在では、ロマン派以降のピアノ音楽の大家の作品群と比べれば特別難しい曲ではなくなっているが、それでもなお演奏は困難を極める。また、リストがベートーヴェンの交響曲をピアノの為に編曲したものが存在するが、それらと比べれば、このピアノソナタは比較的易しい。
超一流のヴァイオリン奏者、パガニーニが作曲したヴァイオリンの難曲として知られ、作曲当時はパガニーニ自身以外には演奏が不可能であった。しかし、この作品の持つ魅力は多くの音楽家の心を捉え、さまざまな作曲家によって主題が引用されている。この曲の存在によって、作曲技巧や演奏技巧が大きく開拓された面は否めない。現在でも超絶技巧の難曲として知られるが、一流の演奏家の中には完璧に弾きこなしている人もかなり多い。
タイトルからもわかるように、超絶技巧を要することが目的となったピアノのための練習曲である。ピアノのパガニーニを目指したリストの代表曲である。一般の演奏家にも演奏できるように難易度を少し落とした第3版が現在では普及しているが、リストが超絶技巧の極致を目指して作曲した第2版は特に演奏困難とされ、リスト以外には演奏不可能と言われた。現在ではジャニス・ウェッバーとレスリー・ハワードが録音を残している。
演奏不可能とのレッテルを貼られ、当時の第一線のヴァイオリン奏者に初演を断られた作品。しかし現在では、早熟なヴァイオリン奏者が10代で弾きこなしてしまうことも珍しくない。
は第一楽章がオクターヴの速い動きで事実上の演奏不可能の作品である。解決譜としてのOssiaで多くのチェロ奏者が弾いている。
パウル・ヴィトゲンシュタインの委嘱で書かれたが、彼は「一音も理解できない」として取り上げなかったため、作曲家の生前には一度も演奏されることは無かった。ただし実際には、様式上・技巧上ともに特に大きな困難があるわけではなく、演奏は十分可能である。菅原明朗は「この曲こそプロコフィエフの最高傑作だ」と称え、ピアノと吹奏楽の為に編曲したヴァージョンを残している。
十二音技法によって作曲されている。ただし、急-緩-急の3楽章から成り、両端楽章の終わり近くにカデンツァがあるなど、伝統的な協奏曲の構成に従ってはいる。作曲者はヤッシャ・ハイフェッツに初演を依頼したが、ハイフェッツはこの曲を演奏するか否か散々考えた末、結局「研究しただけ無駄だった」として辞めてしまった。結局初演はルイス・クラスナー独奏、ストコフスキー指揮フィラデルフィア管弦楽団により行われた。作曲者自身は生演奏を聴いていないとされる。
1990年代初めドナウエッシンゲン現代音楽祭がカールスルーエの作曲家フォルカー・ハインに管弦楽の曲を委嘱したが、度重なるリハーサルにもかかわらず演奏困難ということでその年の公開演奏が中止になった。次の年もう一度だけ初演が試みられたが結局不可能で、またしても初演を断念させられた。その楽譜は当時の展示即売会で一般公開され、色々な同僚作曲家の意見が聞かれた。現在に至るまで演奏されていない。ブライトコップフ社によって出版されている。
チャンスオペレーションを厳格かつ極度に徹底したヴァイオリンソロのための作品集で、「作曲するのも演奏するのもほぼ不可能に近い」音楽になることを前提に作曲された。しかし、第18曲目の演奏困難度をめぐって1-16曲目までの初演者ポール・ズーコフスキーと意見が対立し、作曲が中断された。その13年後にアーヴィン・アルディッティの助力で作曲が再開されて、無事32曲の完成に至った。現在この作品の全曲演奏が出来るヴァイオリニストはヤノシュ・ネギーシーとアルディッティの二人しかいない事から考えて、最も演奏不可能に近いヴァイオリン曲といえる。
月曜日のたわわの件でかなり自分の中で揺らいできてるので、教えてほしい。
NGなんてないって言う意見もあると思うけど、少なくともウマ娘の二次創作については著作権が優先されてたと思う。
元々深く考えずに人の意見を鵜呑みにした挙句に雑に消化する人間なので、この解釈も間違ってたらすまない。
元々二次創作に親しんでいたのもあるので、表現の自由は権利の一つとして守られるべきと強く思っていた。
ただ、最近のいろんな騒動で表現の自由の観点から規制に反対する立場に疑問を感じてきた。
適当に思いついたリストを挙げるので、OK/NGのラインなり判断基準を答えてほしい。
自分なりの考え方も記した。今の私の迷いや思い込みなどが現れていると思う。
→特に前3者はゲームの規制などで並べられているので、羅列した。どちらにせよ表現の自由なはず。
→そのゲーム規制について。あくまで自主規制であり、表現の自由として規制されてはいないしされるべきでないと思う。
→個人的に迷っているポイントその１。表現する自由はその表現を忌避する他の人間が利用せざるを得ない空間でも守られるべきか？
はっきりいってしまえば"お気持ち"だが、少なくともゴア表現が市役所の玄関に飾られるのは権利の濫用だと思う。
未成年者略取という概念を踏まえると、青少年には十分な判断力がないのだから、規制されるべきではないだろうか。
一方で、未成年者自身がそういう作品を作った場合はどうなのだろうと考えると、規制するのもどうかと思う。
なお、創作・実在に関わらずあらゆる事象はその人に影響を与える可能性があるという私なりの前提がある。
明らかな論点として、どこからがそういった表現になるのか？という問題がある。
（フェミニストの人達はかなり厳しめの判定になるし、表現の自由を重視する立場は緩めになる）
個人的に迷っているポイントその３として、結局はこの判断基準の相違に過ぎないのではないかという疑問がある。
そこで、何らかの規制があるべきという前提条件において、以下の内容も考えてみた。
表現の自由は規制する状況などないという人は読み飛ばしてほしい。
→バラエティ番組で問題になっている暴力やいじめ表現は、どちらに当たるのだろうか？規制されるべきだろうか？
→"性的な表現"でいうなら、グラビアアイドルやジャニーズメンバーのセクシーなグラビアなどはどうだろうか？
→漫画やアニメなど、いわゆる2次元はこのカテゴリにあたる。実在する人物と差異はあるべきだろうか？
→比較対象として。ただ、これも結局は”どこまでが穏当か？"という問題をはらむ気がする。
豚肉を食べるシーンはムスリムにとっては見たくない表現なのかもしれない。
→二次創作の大半は著作者の黙認という前提だが、合っているだろうか？
→2番目はいろんな裁判になっていた気がする。プライバシーが優先されたと思うけど、どうなんだろう。
人物でなければウマ娘の例も挙げられなくもないが、あれは馬主が同意あった対象だけを使用している、はず。
赤羽駅から渋谷駅に行くとき、ちょいちょい古ぼけた謎のホームを見かける。
しょっちゅう通るわけではないので、通る度に「こんなんあったな」と思いつつ通り過ぎる。
先週通った際、不可解な事実に気づく。完全に無人ホームなんだよ。
明治神宮のすぐ近くのようなので、わざわざ山手線に乗り換えて原宿駅で降りる。
原宿駅からあたりをつけた場所へトボトボと進むと、徒歩3〜4分程度の場所に古びた謎のホームを発見した。
あっさりしてんな。
線路上までフェンスが伸びてて、何の為にあるのかよくわからん。
門の前に「駐車禁止」と書かれた何かが置いてある。看板ではないけど何て言うんだろうな。水かなんか入れて重しにするやつ。
会社名が書かれてる「鉄建」だそうだ。ぶん殴ってきそうな名前だ。
周りをぐるっと回ってみたが、特に入れそうな場所はない。あと割と広い。
電車に乗って謎のホームの横を何度か往復すると、チラチラと工事用の機械が見える。
工事をしてるということは、今は使ってない。
原宿駅の旧駅舎かと思ったが、そこそこ離れてる。原宿駅から徒歩数分だからね。
場所が分かれば調べようもある。ググった。
やたら質素なのは、作った時に大正天皇の体調がよろしくなかったから、目立たない為なんだとか。
昭和平成では何度か使われたようだが、令和に使用された事はなく、あちこち錆び付いててすぐには使えないらしい。
2016年に一般公開された事があるようだが、また一般公開される日は遠そうだ。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
さっき見たのがこれ。
https://twitter.com/catsgravity137/status/1485757973121351680
要するに、
という素人の主張。
この例のように、せっかく書いた論文が、中途半端に知った顔をした素人に捻じ曲げられ、世に広められてしまう。
当然だが、わざわざ著者が素人相手に反論訂正するわけにもいかない。
書くことはつらい目に遭っている人の心のバランスを取る効用がある。
古くは司馬遷だったり、マルキドサドだったり、それを翻訳した澁澤だったり日本のヤクザ小説家だったり、政治家だったり。
それぞれ集中しやすい獄中からなかなかの名作本を書いている。https://scrapbook.aishokyo.com/entry/2015/12/20/112208
また自分は本をかけなくてもインタビューに答えて出版してもらう形で印税を得る人もいる。
それではてなブログもとりあえずは「自分を表現してみませんか、自分を振り返る効用がありますよ」ということで
１０年つづいてきた（今キャンペーンをやっているhttps://blog.hatena.ne.jp/-/campaign/hatenablog10th-question10 万ねん筆だのインクだのの筆記具をくれるらしいが、万年筆って蓋をしていても一か月もすれば中身のインクがカラカラに乾くから個人的には嫌い）。
ダイアリーといいながらも、わりあいに小説だったりエッセイと呼べる程度にクオリティの高い長文が投下されていた。
はてなダイアリーはすんなりとはてなブログに移行され、どちらもたしか６万字程度が上限だった。十分な長さだ。
ところが横の連帯はキーワードリンク程度しかない寂しい修行場のような場所でもあった。
そこではてなハイクができた。上限たしか１万字程度で、論戦には十分だが基本的には猫や鳥や料理の写真と大喜利が主流であった。
だがツイッターの台頭が「牢屋や修行場のようにしずかでいること」あるいは「なごやかな大喜利や生活報告にとどまること」をネット民に許さなかった。１４０字の揚げ足取りがネットの主流になってしまった。
ツイッターに論客（）を取られたあとのはてなには１００字のはてなブックマークとはてなダイアリーのシステムをほぼそのまま流用した使いづらいはてなアノニマスダイアリーが残った。
ここでいいたいのは、増田で書くことには効用が薄いということだ。人前ではいえないこともＳＮＳでいくらでも本名から遠いハンドルネームをつくって書いたり同士を募ったりすることができるのに、そのハンドルネームによるアイデンティファイさえ捨てて言いたいことなど、この増田をみていてわかるように
「もっと俺をみろ」
「パンティ見せろ、しゃぶれ」
という５歳児のような（いや性欲がある分５歳児より悪い）我欲の塊でしかないのである。
まるで、「蜘蛛の糸」でお釈迦様が糸をたらした地獄そのものだ。ありもしないチーズを探すネズミどもの居場所がここなのだ。
だから、文章を書くときは、ここ以外で書け。効用を求めるのならIDをつけられる場所で書け。できれば自分だけのために書け。
ここで書きだしたら終わりだと思え。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
442あとで/3232users 京都大学、Pythonの基本を解説した無料の教科書「素晴らしすぎる」「非常にわかりやすくて良い」 | Ledge.ai
297あとで/1576users DX白書2021：IPA 独立行政法人 情報処理推進機構
232あとで/2114users 個人的にワーキングメモリーを鍛えるのに役立ったなと感じた事を挙げる。 .. | anond.hatelabo.jp
216あとで/1250users JavaScriptを完全無料で学習できる最強の厳選コンテンツを大公開！ - paiza開発日誌
208あとで/1289users 富士通の実践知が詰まったデザイン思考のテキストブック公開 | 富士通
207あとで/1171users Amazon.com、同社内で使われていた従業員向けのセキュリティオンライントレーニングを無償で一般公開、日本語版も提供 | Publickey
183あとで/2525users 当たり屋対策の集合知 | anond.hatelabo.jp
168あとで/1131users ほとんどのマーケティング従事者が興味を持たない「エーザイの統合報告書」がヤバいから読んだ方が良いぞ！という件｜池田紀行@トライバル｜note
168あとで/1717users この国に生きるすべてのあなたへ | 立憲民主党
161あとで/1040users アプリケーション・エンジニア職位ガイドライン詳細 | 株式会社ゆめみ
158あとで/922users 【Python】専門書や論文を読みたいけど数学が苦手・わからない人向けのコードを読んで学ぶ数学教本 - Qiita
154あとで/1013users モダン JavaScript チートシート | GitHub
152あとで/1339users バーグハンバーグバーグ社員に聞いた、ブックマークしてる便利なサイト | オモコロブロス！
151あとで/772users できるだけ嘘を書かずに計算量やオーダーの説明をしようとした記事 - えびちゃんの日記
142あとで/776users AWSアカウントを作ったら最初にやるべきこと 〜2021年版〜 #devio2021 | DevelopersIO
139あとで/742users LOG関数で2を底とする対数(二進対数)とO(logN)の意味を知ることは情報処理の基本である【Excel】 - わえなび ワード＆エクセル問題集
138あとで/1345users 「要領がいい子」とそうでない子の、勉強法のちがいについて。 | 不倒城 | Books＆Apps
136あとで/952users ファイルを掴んでいるプログラムを特定する方法 - misc.log
134あとで/868users 「これぐらいのことはできていて」は勝手な期待 観察・考察・選択のサイクルで相手の力を引き出す「誰も嫌な思いをしない変化」 | 椎葉光行 | logmi
134あとで/1266users 失業したらiDeCoの落とし穴にハマった件 - 35歳からの中二病エンジニア
132あとで/913users 一年半同じチームで色んなふりかえりをやったので手法と学び紹介していく | bayashi | SpeakerDeck
131あとで/867users インフラエンジニアを20年やってて初めて知ったtopコマンドの表示を劇的に見やすくする方法 | 株式会社ビヨンド
129あとで/1621users おくすりレシピ | うつ病
126あとで/779users レビューの仕方 | Yosuke Furukawa | SpeakerDeck
122あとで/675users CDNは5時間で開発できる | POSTD
120あとで/1073users デザインは、見た目じゃない | 山田奈々 | NHKニュース
118あとで/1184users 皇の器 - 織部匡 | 少年ジャンプ＋
116あとで/1079users 『火の鳥を時系列順に読んで立ち直れなくなろう』ファンも未読勢も通しで読んでみたくなる構成図「こうなってたのか」 | Togetter
114あとで/1355users 源氏物語が好きすぎてAIくずし字認識に挑戦でグーグル入社 タイ出身女性が語る「前人未到の人生」 | Ledge.ai
113あとで/514users [2021年版]AWSセキュリティ対策全部盛り[初級から上級まで] というタイトルでDevelopersIO 2021 Decadeに登壇しました #devio2021 | DevelopersIO
めっちゃ巨大施設やが？anond:20210821104051
▼大型低温重力波望遠鏡KAGRAとは
https://www.nao.ac.jp/research/telescope/kagra.html
▼スーパーカミオカンデ 公式ホームページ
http://www-sk.icrr.u-tokyo.ac.jp/sk/library/video.html
▼GEO SPACE ADVENTURE 2019 | GSA-HIDA.jp
▼ 今年はおうちで地底探検|スーパーカミオカンデ・KAGRA オンライン一般公開
https://sites.google.com/g.ecc.u-tokyo.ac.jp/sk-kagra-online-open-days/
平井大臣の「干す」「脅しておいたほうがいい」発言から、文春によるベンチャーへの発注を指示しているのではないかという疑惑を受けて、6月18日の記者会見で説明と記者による質疑の内容を書き起こす。
なお、関連として6月11日の記者会見の書き起こし（anond:20210611202929）、文春で記事にされた音声データの書き起こし（anond:20210617120138）なども参考にしていただければと思う。
今回の書き起こしの元データは政府インターネットテレビ（https://nettv.gov-online.go.jp/prg/prg22838.html）である。YouTubeの「平井卓也（デジタル改革担当大臣）」チャンネルで公開されている記者会見動画（https://www.youtube.com/watch?v=1NH4PkfgIP0）では、質疑応答が大幅にカットされて（ダイジェスト版）いたため、書き起こしに使えなかった。
なお、動画が長いこともあり、記者会見の中の質疑応答の部分のみの書き起こしとしている。
----
記者：さっそくですけれども、いま言った企業名の話なんですけれども、まあ名前を出していないとおっしゃるんですけれども、あの一方でその会話の中ではですね、東大の先生のお名前を挙げて、一緒にやっちゃっていいよ、とかですね、彼の抱えているベンチャー、ベンチャーでもないな（平井大臣：まあそれは、学生さんもいるからね、あそこは）、はい、ああ、そういう意味なんですね、で、そこの顔認証ははっきり言って、NECよりは全然いい、という風におっしゃっていますから、具体的な企業を念頭に置かれて話をして
平井大臣：アルゴリズムです。要するに、松尾研究所で、アルゴリズムを研究している若い研究者がやっている、最新のアルゴリズムは、もう相当進化しているよと。だから、今ある技術だけを見るなという意味で言っています。
記者：あの、じゃあ具体的な企業を指して、あのベンチャーっていう風に言っているんですけれども、
平井大臣：ベンチャーも、ベンチャー、あの、ベンチャーも育っているし、ベンチャーの卵もいるし、そして、大手企業にも、どんどん協力しているんですね。松尾研究所は、NECさんにもずいぶん協力していると思います。
記者：わざわざNECをここで、対象に比較に出しておっしゃっているのはなぜなんですか。
大臣：これはさー、オリンピックの話の減額の話なんですよ。前の段階は。その2つの調達を、無理矢理くっつけて、お話になるのもいかがなものかと思います。
記者：えっと、オリンピックの減額の話の中で、デジタル庁の入退室管理の話が出て
平井大臣：まずねー、デジタル庁の入退室管理っていう調達は、まだないんですよ。だから、正直申し上げて、入退室管理は顔認識じゃないんです。現状では。なんで、いずれそういうのを検討するのであればと、いうことです。
記者：で、そこについて、システムを実験的に入れてくれてもいいよと、それで東大の先生の名前を出して、一緒にやっちゃっていいよと、言っているわけですから。これからそういうのを発注しなさいよと、いう風に聞こえます。
平井大臣：それね、本当にそういう風に聞こえるっていうのは、よっぽどそういう風に、なんかバイアスをかけて思わないと、思えないと思いますよ。要するに、みんなその、既存技術にこだわるから松尾先生に聞いて、最新の技術をみんな勉強して、それから、要するに、調達を一気にできないんだったら、いろんなところでいろんなものを実験したらいいんじゃないの、ということです。
記者：それと、オリンピックの減額の話というのは、どうつながっているんですか。
平井大臣：だからつながっていないんですよ基本的には。だからNECの技術だけじゃないよっていう意味で言っているんです。
平井大臣：まずね、ちょっと一つだけ、あの、企業の名誉のこともあるので。企業名は、言っていないし念頭にないし、私そういう企業の名前を憶えていないんですよ。もともと。ですから発言したことは絶対ないと思って、オリジナルの音源を、ありますから。言っていないっていうことをこれ立証できるんです。それを何度も何度も調べているのに。なんで特定の企業の話をですね、どっから、誰かが、無理矢理くっつけているのかがわからない、と、そういう風に申し上げているので。
記者：あのー私が言っているのは、特定の企業名のことを言っているわけではなくて、そこの顔認証という言い方をしていますから、大臣の頭の中には
記者：確認したいこと2点ありまして、まず1点が、音声、元のオリジナルの音声なんですけども、そちらで立証できると大臣おっしゃっているんですが、そちらのオリジナルの音声を、一般公開などすることは考えていらっしゃいますでしょうか。
平井大臣：これは一般的に内部の会議の音声データですから、要するに、公開を前提にしていませんが、今回こういう事態で、今後どのようにこの事態が発展するかわかりませんけれども、また関心を集めるかわかりませんけれど、異例中の異例ですけど、事務方に、法律に触れないんであれば、公開するということも検討するということに、まあ検討をお願いしようと、は思います。ただ現時点では、公開するという気があるわけでは、ないんですね。ただし、こちらで何度も何度も確認をすることができたと。これが、私はデジタル時代だと思います。
記者：ありがとうございます。あともう1点が、先ほど、第3者のコンプライアンス委員会を立ち上げるとおっしゃっていましたが、こちらあの、確認なんですが、この週刊誌に報道された件も、まずあの調査するとともに、いずれはその一般的に、デジタル庁が発足後は、コンプライアンスのこともやるって感じで
平井大臣：違います違います、コンプライアンス委員会っていうのは、まず、9月1日に発足するので、で、デジタル庁がその後引き続いて、責任を持つシステムもいくつかあるんですね。そんなに全部足したって、そんな数はありません。ないとは思います、直接やるものに関しては。ただ、今後やっぱりデジタル庁が関わっていくシステムであるんだとしたら、徹底的に、現時点でチェックできるものはチェックしてほしいなと、思いますが、これはあの、なんていいますか、コンプライアンス委員会はできるだけ早く、私はもう、気持ちの中では来週にでもスタートさしてほしいなと、まあ事務方が悲鳴を上げていると思いますけれども、スタートさしていただいて、スケジュール的に言うと、もうできるだけ早くやってもらいたい。そして、私の発言を対象にするかどうか等も含めて、コンプライアンス委員会に考えていただいたらいいと思います。ですから、はっきり言って、私の気持ちですよ、私の気持ちとしては、コンプライアンス委員会には、徹底的に私自身を調べてもらいたいと、いう風にも思っています。
記者：別件なんですけれども、デジタル庁のオフィスについてお伺いします。今週末にも荷物搬入とも聞きますけども、現状どのようになっているのかまずお聞かせください。
平井大臣：これあんまり詳しくないんですいません、ちょっと待ってください。えーとですね、デジタル庁のオフィスの場所は、東京ガーデンテラス紀尾井町になって、来週21日からIT総合戦略室および番号制度推進室の職員が勤務するということでございます。
平井大臣：あの、詳しいこと知らないんで、これIT室に聞いてください。私自身が引っ越すわけではまったくないんで、細かいスケジュール聞いてません。
記者：改めてその、なぜこの築年数の浅い、2016年にできたところですけれども、都心の一等地のビルに、デジタル庁が入る必要性があるのか、その辺をお聞かせください。
平井大臣：今の入っているIT室の場所も都心の一等地ですよね。虎ノ門もそうですよね。で、これはね、国会や霞が関から近くて、そして官民の人材500人以上が一体的に共働できると、共に働くということで、今もそうですけど、ワンフロアの面積が非常に大きいところを探したという風に聞いています。であの、調達の件に関してはもう事務方に聞いてください。
記者：今回のこの週刊誌報道から始まって、コンプラ委員で検討する話とか、一連の流れと、あと今、策定しようとしている調達ルール、が、今後調達ルールの策定に今回の一連の報道とそれに伴うコンプラ委員の検証結果というのがどういう風な影響を与える
平井大臣：というより、もうずいぶん前のコンプラ委員会とその調達ルールの検討というのはもう、本件起きる前からみなさんには記者会見でお話ししていたと思うんですけど、今回の事案がいろいろと世間を騒がせているので、前倒ししようということです。で、今動いている委員会も最終的には一つに全部統一をされて、デジタル庁としてのコンプライアンスの指針ということでまとまっていくんだろうと、思っています。
記者：これまでの日程のスケジュールを前倒しになると考えていいですか。
平井大臣：ですからデジタル庁を発足してからというよりは、ちょっと早くなるということですね。
記者：今の質問に関連するんですけれども、先ほど大臣できるだけ早く来週にも、っていうその前倒しの時期について思いを語られていましたけれども、現実的には多分外部の有識者をいれるのであればその調整とか、時間がある程度かかると思うんですけれども、その大臣の思いとは別としてですね、現実的にはどれ位の目途になりそうかっていうところ、
平井大臣：もうできるだけ早くです。できるだけ早くやってもらいたいし、世間が初めて調達というものに、一般の方々も含めて関心を持つことになったと思います。これは私は非常にチャンスだと思っていて、このときに調達とはいったいどういうものなのかと、調達に必要な透明性とはなにかみたいなものを、国民の皆さん全体で関心を持って議論していただきたいという思いもあって、このように申し上げたと、いうことでございます。
記者：あらためて確認なんですが、この前倒しして設置されるコンプラ委員会は、民間から来られている職員の方の服務規律の順守っていうところをデジ庁発足前からきちんと研修していこうっていうのが一つ大きくあると思うんですが、個別のそのオリパラアプリですとか、そういったシステム、まああと先ほど大臣がご自身の発言についても、という、そういう個別の事象についても、調査、調べる、チェックするというか、そういった機能も有するという理解でいいですか。
平井大臣：例えばオリパラアプリであるとか、ワクチン接種管理システムであるとか、今後作らなきゃいけないであろうワクチンパスポート、これ報道されているベースですとか、こういうもの、それもうベースにあるシステムがあるわけですから、当然対象になるという風に考えていて、要するに、発注のプロセスを、表に国民の皆さんに説明して説明責任が果たせるかどうかということ、疑念の目を持たれないように、今回私は減額交渉の途中から本件にかかわったということでございまして、私自身も本件が減額されていなければですね、要するに、全然関与していないといいますか、組織は私の関与のもとにありますが、IT担当大臣というのは、調達の決済というのに直接関わるものではございませんので、そういう意味で、初めて今回、いろいろ調達というものに、参加したうえで、いろいろな発言もしてしまったと、いうことでございます。ですから、私の発言が、やっぱりその、言葉遣いということは当然反省すべき点はあると思いますが、なぜその発言をしたかということに関しても、できればコンプライアンス委員会に、調べていただきたいと、いう風に思います。
記者：過去の話になるかもしれないですけれども、オリパラアプリの発注過程についても一応検証するという
記者：まあ今年ですね。
記者：ここに来る前にですね、野党のヒアリングが9時半からあったんですけれども、その場でですね、さっき大臣が、松尾研究室の（平井大臣：ん？）、松尾研究室に聞いてくれっていうか、もう少し時間かかってあれですけれども、そこの顔認証のそこのっていうのは、松尾研究室だっておっしゃったんですけれども、その、野党のヒアリングの席では、答えた方がですね、特定の企業を念頭に置いていると思うって発言をされているんですね。それは違うんですか。
平井大臣：もしね、まず当事者に聞いてください。念頭にあるかどうかは。だから念頭にないって。私に聞いてくれたらいいんですよ、それは。事務方が私の頭の中までわかるわけないじゃないですか。
記者：ということですね。
平井大臣：うん。
----
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
400あとで/2455users ハーバード大のプログラミング講座を日本語化 無料で学べる「CS50.jp」公開 - ITmedia NEWS
340あとで/2437users 米ハーバード大学のプログラミング授業 日本語訳が無償公開 誰でも聴講可 | ツギノジダイ
335あとで/2327users 東大が無料公開している超良質なPython/Data Science/Cloud教材まとめ (*随時更新) - Digital, digital and digital
292あとで/1762users 新人の方によく展開している有益な情報 – Qiita | kazuo_reve
244あとで/1441users 知っておきたかったLinuxサーバ設計、構築、運用知識まとめ - hiroportation
228あとで/1463users Googleが提供する無料のAI講座受けてみた 1時間で機械学習の基礎がわかる | Ledge.ai
227あとで/1355users 無料で読める、東大／京大の「Python教科書」電子書籍：AI・機械学習の無料電子書籍 - ＠IT
220あとで/1750users 研究の話 | 医療法人豊隆会 ちくさ病院
208あとで/1145users ブラウザレンダリングの仕組み | Aki Kahamura | Zenn
191あとで/1151users すべての働く人におくるストレスマネジメントの基本 | knowledge / baigie
188あとで/1023users 【図解】https(SSL/TLS)の仕組みとシーケンス,パケット構造 〜暗号化の範囲, Encrypted Alert, ヘッダやレイヤについて～ | SEの道標
187あとで/989users 認証と認可の超サマリ OAuth とか OpenID Connect とか SAML とかをまとめてざっと把握する本 | ほげさん | Zenn
180あとで/1161users すべての開発者へ。すごいGitHubリポジトリ10選 – Qiita | baby-degu
179あとで/2080users 山本ゆり（syunkon レンジは600W) on Twitter: "今まで紹介したレンジのハンバーグで個人的に優勝。この手間でこの味になるかと驚くほど簡単で、本当に美味しい(包丁不要。ボウルで捏ねないからヌルヌルの洗い物もナシ) 卵の有無、練り具合、つなぎの量など何度も試作しました。柔らかくジュ… https://t.co/BXntIVz5NQ"
169あとで/1342users 『スタンフォード式 最高の睡眠』を読んで、睡眠について知らないことがまだまだあったのかと感動しました - おたまの日記
162あとで/1388users CS50 for Japanese(ハーバード大学 CS50 の日本語版翻訳プロジェクト): コンピュータサイエンスの入門
161あとで/1375users カレースパイス調合の基本から、スパイスカレーや肉のスパイス漬けを極める（小林銅蟲／イナダシュンスケ） - ソレドコ
154あとで/743users 世界一わかりみの深いOAuth入門 | Noriyuki TAKEI | Speaker Deck
153あとで/1529users TOKIO国分太一さん「センスのいい、もらって嬉しい手土産知りませんか？」見ているだけで楽しい「推し手土産」が集まる - Togetter
149あとで/980users 機械学習の研究者を目指す人へ | Hiroshi Takahashi
149あとで/1629users お前らの登録してるyoutubeチャンネル教えろよ | anond.hatelabo.jp
144あとで/1277users 【更新】創作する人は必読！書評家が下読みで感じた「応募小説の問題点」がめちゃくちゃタメになる - Togetter
144あとで/1225users ナビつき！ つくってわかる はじめてゲームプログラミング | Nintendo Switch | 任天堂
144あとで/1668users 政府向けシステムの話をするときの前提知識 | anond.hatelabo.jp
135あとで/656users フロントエンドのパフォーマンスチューニングを俯瞰する - 30歳からのプログラミング
133あとで/998users 社員用に作った文書校正ツールを一般公開した - gecko655のブログ
133あとで/2245users ため池に落ちると、なぜ命を落とすのか(斎藤秀俊) - 個人 - Yahoo!ニュース
131あとで/1170users 真っ先に変えるべきは日本人の「思考」 オードリー・タンが貫く「透明性」と「多様性」：「前例がない」をやらない理由に（1/5 ページ） - ITmedia ビジネスオンライン
126あとで/796users DOM Events | Alex Reardon
124あとで/912users 「結果が出ない焦り」と向き合う方法｜柴田史郎｜note
124あとで/598users MySQLとインデックスと私 - Speaker Deck | yoku0825
Google製のSNSとして広く利用される可能性もあったんだろうか
自分が使った頃はAKBの記事ばかりで除外設定するも流れ込んで来て
使い込む前にやめてしまったという感じだった
Google+を最も多用していたのは間違いなくIngressでした。理由は複数存在しますが、
そんな感じ。Ingressは2陣営による争いが基本なのですが、面白いことに常日頃から陣営間の情報交換はあまり行われず、片方の陣営のみでコミュニティが完結するのが通例です。情報の秘匿に関してもかなり徹底されているので、中々Ingressに関するオープンな情報共有というのはしづらいのです。
Google+はそういう公開の場として非常に重宝されました。ときに作戦のSiterpを書いたり、ちょっとした日記にしたりとTwitterでは難しいことでもGoogle+なら平気、という人は数多くいたのです。
Google+では情報公開の範囲をかなり自由に設定できます。Twitterでは自分のフォロワーにだけ伝わるようにするには、鍵をかけるなどの大雑把なククリでしかゾーニングが出来ません。一方でGoogle+では「一般公開」「特定のフォロワーやサークルに通知」「コミュニティ内部だけの会話」「カテゴリーごとの投稿」など多彩です。
一般公開とはTwitterと同じで全体に公開され誰にでも見れます。Ingress界隈では俗に「パンコ」と言われていたやつです。
しかしそうではなく、例えば「緑陣営の人には見せられないので青の人たちだけに見えるようにしたい」という投稿でも、共有先をそういう人たちだけに設定することが可能です。Google+にはもともとサークル機能があり、フォロワーを属性ごとにサークルに分類することができます。そうすることで一つのアカウントで複数の話題を投稿することが結構楽になります。ただこの機能は後続のカテゴリー機能の登場であまり重要視されなくなります。
カテゴリー機能とは、自身の投稿をカテゴライズすることです。Ingressの話題なら「カテゴリー：Ingress」「カテゴリー：Ingressミッション」などとし、自分の投稿をそれに紐付けることが可能です。これの何が良いかというとカテゴリーごとに共有先を予め設定しておける点です。つまり「カテゴリー：Ingress」をIngressの共有先をIngressエージェント限定にしておけば、そのカテゴリーとして投稿するだけでゾーニングができます。また人をフォローせずにその人のカテゴリー自体をフォローすることも可能だったりします。これが地味に強力なんですよね。
共有範囲が自由自在なのはIngressというゲームの性質にマッチしています。
ちなみにカテゴリの使いやすさからか、ブックマークや自分だけの日記的に使うことも可能です。
IngressではGoogleのサービスがかなり多用される傾向にあります。そのため、Google謹製のサービスであるGoogle+との相性の良さは格別です。
Youtubeや他のGoogleサービスとの連携を共用されていた時代もあり、Googleアカウントを持っているとGoogle+を使う敷居は非常に低いものでした。にもかかわらずその無理やりな連携に悪意を感じることもあったり、機能面で優れていてもTwitterやFBより難しそうに思える部分もあり、存在を知っているし始めやすいけど使っている人は殆どイないSNSでした。この誰でもすぐに使えるのに誰も使っていないSNSというのはアングラなIngressにとっては丁度いい環境でした。
ちょうどIngressが普及しだした時期に実名制が解除されたのも良かったと思います。
利用者数の問題でしょうね。Youtube等と強引に連携したのに伸びなかったのは痛手だったかと。
あんなにIngressで普及したのはまさにIngressのためにあるような絶妙なさじ加減だったからで、逆に言えばIngressのような世間から隔絶された存在以外にはなじまなかったんでしょう。
あと、最初に実名制を強要していたのと、以降も投稿名がGoogleアカウントと紐付けられるのが嫌って人は一定数いたのでは。
