現代人向けの平和教育

慰霊の日の前後の沖縄は平和教育週間といった趣になる。小学校の読み聞かせでも、沖縄戦や平和にまつわる本を読んでくださいというリクエストが来る。

沖縄では、地域のどこで戦闘が行われた、ここの人たちはあそこにある壕にこもった、といった口伝を伝える形で、内地より100倍くらい濃い平和教育が行われている。

戦後も80年が近づき、戦争体験者の高齢化により一次話者を失いつつあるものの、こうした活動の持つ本質的なリアリティには圧倒されるものがある。

また、たとえば「ひめゆりの塔」には、何月何日にどこまで移動した、誰々(個人名)がどこでどんなふうに亡くなった、という記録が数多く記されている。こうした日数、経過時間、距離といった情報は「数字による体験化」を生む。

描写だけではわからない実感が出ることは、体験しか本当には理解できない人間にとってたいへん重要である。

しかし、こうした「現場のリアル」一本槍で沖縄戦を伝えることについて、それを初めて知った大学生の頃から、オレは何かしら本質を外しているような感触を持っていた。

もちろん、沖縄戦が生活の場で行われた戦争であること、身近な場所で身近な人が犠牲者になったことが、その悲劇の本質のひとつであることは間違いない。

しかしこれらは、本質的であるもののいわば現場だけの「横軸の本質」であり、全体の様相を提示しきれていないように思えるのだ。

全体を示すのに必要な「縦軸の本質」は、沖縄戦が沖縄の防衛のためではなく、国体なる抽象的な価値の防衛のためにおこなわれたものである、ということだと思っている。

日清日露から第一次大戦、シベリア出兵など、日中戦争までの日本の戦争は、防衛の名を借りた帝国主義的欲望の発露にすぎない。

ロシアの脅威を除くための緩衝地帯が必要と言いながら、それと無関係な台湾に兵を進め、朝鮮半島の植民地化では飽き足らずに満州国という傀儡国家を作ったことは、つまるところが領土的野心である。このことは当時も小日本主義を唱える石橋湛山らが指摘している。

日米開戦だけはこれらと違う。日米開戦は、国内の力のバランスがあちらに傾き、こちらから押され、外交に失敗し…と、誰の意志でもなく成り行き任せによって生まれた、誰から見ても最悪の結果である。

そして、終戦前にしきりに言われた「国体の護持」という特殊なキャッチフレーズは、こうした開戦の経緯を反映している。それまでに叫ばれた八紘一宇だの大東亜共栄圏だの悠久の大義だのといった愚にもつかないキャッチフレーズと、終戦前に強調された「国体の護持」とは、少し性質が違ったものである。

ひとつには、「国体の護持」、という言葉があまり勇ましくないことがある。それまでのキャッチフレーズと違い、「国体の護持」には前進、発展、永遠、といったイメージがない。いわば後ろ向きのキャッチフレーズなのだ。

もうひとつには、「国体の護持」をする当事者が為政者であり、国民ではないということがある。これは為政者の内部的な価値観であり、彼らは他人ではなく自分にこれを語っているのだ。

国体の護持なる言葉の本質はここにある。「国体の護持」とは、大本営から御前会議に至るまでの日本の中央部が持つ、変化への恐れの素直な発露なのだ。日常を継続したいという、いわば地に足のついた欲求を言葉にしたものである。

地に足が付いているというのは、それに価値があるという意味ではない。欲求として、より根源的であるというだけのことだ。より動物的な欲求であるがために、いざ言葉として表現されたときに、より強い方向性を生むということである。

当時、国体とは何かという定義はどこにもされておらず、これを護持することにどんな意義があるのかは明確に言語化されていなかった。それが何かを答えられたような者は居なかった。純粋な「言霊」であるとも言える。

そして、沖縄は大本営にとって護持すべき国体の一部ではなかった。国体護持のための縦深戦術陣地のひとつでしかなかったのだ。

これは結果的にそうなったという話ではなく、1945年1月の帝国陸海軍作戦計画大綱に:

四 皇土防衛ノ為ノ縦深作戦遂行上ノ前縁ハ南千島小笠原諸島硫黄島ヲ含ム)、沖縄本島以南ノ南西諸島、台湾及上海付近トシ之ヲ確保ス

 右前縁地帯ノ一部ニ於テ状況真ニ止ムヲ得ス敵ノ上陸ヲ見ル場合ニ於テモ極力敵ノ出血消耗ヲ図リ且敵航空基盤造成ヲ妨害ス

と書かれたときには、それが陸海軍の間で同意されるレベルで、既に事実であった。

大本営が沖縄守備の第32軍から兵力の相当な部分を引き抜いて台湾に回したことも、「軍官民共生共死の一体化」という方針で沖縄政府や民間を徹底的に巻き込んだことも、沖縄のためではない。前縁防衛の「コスパ」を上げるためである。

彼らには、沖縄県民を守る気など一切なかった。そんなことを歯牙にもかけないことが、むしろ常識であった。

(そして実のところ、日本の国土全体が、彼ら中央の人間にとって、長い長い縦深陣地でしかなかった。国民を守る気など一切ない。そうした空気を肌で感じていた小松左京が、本土決戦の起きたパラレルワールドで動員された学徒部隊「黒桜隊」での主人公の体験を描いたのがデビュー作『地には平和を』である。)

この間読んだものに、いまの若者はみんなが決めたことに弱い、それを必ず守らなければならない、背くことはできないと考える傾向にある、という話があった。

これは昔からの日本人の宿痾、「空気の問題」と呼ばれているものに非常に近いのだが、現代はさらに強化されているという。

たしかにそれは、若者と話すたびに感じることである。舌を巻くほど優秀な人から、学業的には残念なカテゴリーに位置づけられる人まで、彼らは異様に行儀が良い。空気を壊したがらない。

それは、よく言われるように「失敗を恐れている」と言うよりは、自分の失敗があらわになることで、場の雰囲気が壊れることを恐れているように見える。場の雰囲気にこそ敏感なのだ。

教えている教室で非常によく感じるのは、たとえば多くの学生が「自分だけがわかっていないと思ったこと」を質問できないということだ。「わかった?」と聞くと「わかりました」と答える。しかし、まったくわかっていない。こちらから少し突っ込んだ質問をすると一瞬で破綻する。しかし、何度同じことを繰り返しても彼らは言う。「わかりました」と。

もちろんこうした行動も、日本文化の宿痾のひとつであり、昔からの日本人の傾向といえばそうかもしれない。しかしオレはそうであるとは信じていない。いまの若者文化の「そつのなさへの撞着」は異様である。

ところで、ここには男女差がある。もちろん例外は少なくないのだが、空気を壊さずに疑念を表明するコミュニケーション言語を持っている女子は、まだ素直に自分の考えを口にできる傾向があるのだが、ストレートな言葉で表現しがちな男子たちは、この行儀の良さを内面化してしまっているところがある。

若者が現状に従順で疑念を表明しないことは、社会にとってきわめて危険である。それは変革を阻害する。おかしな現状を変革しようという方向性すらあやふやなれど強い意志、というのは、歴史的には若者の特権であり、その表明により社会がちょっと不安定になり、エスタブリッシュメント(オッサン)に都合の悪いことがいくらか起きたとしても、トータルでは全体が得をする。しかし、そうした道は現状ではかなり閉ざされている。

そして疑念を表明しないことは、社会全体だけでなく、彼ら個人の問題となる。中央の「みんな」と自分との立場の違いを理解せず、なんとなく自他を同一視して、押し付けられたことを「決まったこと」だと従い続ける者は、安易に作られた虚構の構造にやすやすと組み込まれ、やすやすと殺されてしまう、あるいは少なくとも、食い物にされてしまうのである。

現代は個人の能力が増大し、「中央のみんな」にもしっかりした人権感覚を持っている人はきわめて多い。むしろ、地方より中央に多いだろうとオレは思っている。

しかしながら、人間の行動を規定するのは人間関係である。立場だけが人を作る。個人的な人格等とはあまり関係なしに、人間は行動を縛られるのだ。そして人間性とは思考よりも行動によって規定される。

だから、構成人員と話せばマトモな常識人ばかりなのに集団としての行動が非人間的な「キチガイ集団」は、古今東西どこにでも存在する。大日本帝国はそのひとつの例だが、現代の日本国がそうならない保証はまったくないというか、たとえば入国管理局の異様な人権無視のように、時代はすでに危険をはらんでいる。

「中央のみんな」に属する人間は、中央での立場構造のくびきから逃れることはできない。彼らはいざとなれば非情な決定を下す。そして中央と地方の人間関係の近さ(馴れ合い)は、利害対立が起きたときにそれを隠し、中央の立場のみを押し通す隠れ蓑にしかならない。政権の役に立っていれば沖縄の利害を忖度してもらえると思っている者たちは、そこのところを勘違いしている。対等でない関係ができてしまえば、強者は何も理解する必要がないのだ。

立場の違った者の利害に巻き込まれずに要求を通すには、馴れ合わない俯瞰の目と、逆説的だが相手の立場に立って利害関係を考える想像力が必要である。

だいぶ話が遠回りした。

こうした構造を踏まえていくと、現代の沖縄に必要な平和教育とはどんなものか、いくらか見えてくるのではあるまいか。

平和教育は、「ぜったいに避けたいエンドポイント」を体験のリアリティで伝えるとともに、「なぜそれが起きたか」を俯瞰の視点で見せ、「立場が違えば正義は違う」という歴史的事実を踏まえさせた上で、「それを認識するには個人の独立が必要である」という自覚の促進まで踏み込む必要があるし、またそれが可能であるように思うのだ。

実現はどのようにでもできる。教える側が自覚を持つか否かである。

参考文献:

納骨堂であった慰霊塔、慰霊碑、ガマといった「沖縄人の戦跡」が、時代とともにどのように扱われ、それはどのように変容してきたか。そこに働いた力はどのようなものだったか。ということを克明に追った博士論文。

6月23日でいいんですか?

6月23日は沖縄県の「慰霊の日」です。

今日は沖縄県の学校は休み。県庁も休みかな。みんな正午に黙祷したりして、戦没者を偲んでいる。みんなが戦争の愚かさを思い出し、語り継ぐ重要な日。

ではあるんだけど、オレは6月23日が慰霊の日であることに納得がいかない。

6月23日って色んな意味で無難ではあるんですよ。無難ではあるけど、もしオレが決めていいんだったら、この日だけは避けたい、と思うような日でもあるのです。

なぜなら、この日に死んだのは主に沖縄県民ではなく(県民も死んでいるがもっと多数が死んだ日はいくらでもあり)、県民に迷惑をかけまくって逃げた大日本帝国陸軍第23軍司令部の主要メンバーだから。

慰霊の日を定めることも、その日を公休日にすることも、語り継ぐべきことを語る節目の日にすることも大賛成なんだけど。

他に良い日がないし、この日を象徴として積み重ねてきたんだから、これからもそうしておくしかない日ではあるんだけど。

そんな話です。

----
6月23日を慰霊の日とすべき理由はいろいろある。

例えば、昭和20年6月23日は、沖縄戦における組織的戦闘の終了日とされている。県民の間でも、民間人犠牲者がこのあたりから減った実感があるかもしれない日、ではある。

例年の梅雨明けが6月20日あたりで、急に季節が変わって気分が一新するため、昭和20年もそうだったな、という記憶と結びつけやすい日、でもある。

日本国内で公式な戦闘終了日のように扱われている日であり、いろいろと通りが良いのもわかる。

しかしオレは思う。本当にこの日でいいんですか? と。「慰霊の日」を、ここに定めるんですか? こんな日に? 趣味が悪すぎない?? と。

実のところ、昭和20年6月23日は、大日本帝国陸軍第32軍司令部の牛島司令官・長参謀長らが、すべてを放棄して勝手に自殺しただけの日である(22日説あり)。

彼らが司令官牛島満大将名義で18日に出した、最終命令、というのがある:

親愛なる諸子よ。諸子は勇戦敢闘、じつに3ヶ月。すでにその任務を完遂せり。諸子の忠勇勇武は燦として後世を照らさん。いまや戦線錯綜し、通信また途絶し、予の指揮は不可能となれり。自今諸子は、各々陣地に拠り、所在上級者の指揮に従い、祖国のため最後まで敢闘せよ。さらば、この命令が最後なり。諸子よ、生きて虜囚の辱めを受くることなく、悠久の大義に生くべし

翻訳しましょうね。

「大好きな君たち。みんなよくやった。3ヶ月頑張って、もう任務完了だ。君らの頑張りは歴史に残る。ただ、戦場はしっちゃかめっちゃかで連絡もつかなくなって、オレはもう指揮できない。あとはその場で上級者に従い、各自で最後まで頑張ってね。これが最後の命令です。捕虜にならずに死ぬんだよ。」

組織的戦闘が終わったとされる6月23日だが、この日に戦闘がピタッと止んだわけではない。最終命令の日付からも明らかなように、6月15日すぎには日本軍にはまともな抵抗能力がなくなっていた。戦闘は既に下火になっていたということ。

そして重要なのは、32軍司令部は米軍に対して降伏したわけでは決してなく、勝手に自殺して消滅しただけだということ。残存した日本兵は隠れて生活を続け、機会があれば米兵を襲撃し、反撃にあっては民間人を巻き添えにした。

こうした「散発的抵抗」は、日本兵が降伏を信じなかったために8月15日ですら終わらなかった。公式に「戦闘状態が終了」したのは9月初旬である。

司令部が勝手に崩壊して残存勢力が迷惑な武装集団になる現象は、フィリピンをはじめとする日本軍占領下の島々で、しばしば繰り返された。占領地に安全な基地を建設した米軍にはほとんど影響がなく、民間人に迷惑をかけ続けて彼らは生活した。

降伏宣言を出せない日本軍の無責任な臆病さが、この現象を頻発させた。

慰霊の日って、誰を慰霊すべき日なの? 全犠牲者を、というのはその通りなんだけど、この日に定めてるってことは焦点があるよね。主に誰を慰霊しているの?

ちなみに、戦略持久を無視した無理な総攻撃で兵力を失って首里失陥を早め、最終命令の最後に「諸子よ、生きて虜囚の辱めを受くることなく、悠久の大義に生くべし(「捕虜にならずに死ぬんだよ」)」と書き足したのは、この日に牛島司令官とともに自決した長勇参謀長である。

えっ、こんなやつを「県民が」慰霊するの? 無能かつ義務を果たさない臆病な卑怯者を? 死んだ日を記念日にして? まじで?

するんですよ沖縄県民は。沖縄戦で死んだ全員を慰霊する日として定めたから。
馬鹿な参謀長どころか、県民を直接殺した米兵だって慰霊する。沖縄戦の犠牲者は全員慰霊する。これはそういう日なのです。

あーモヤモヤする。

しかし、そうしたモヤモヤ感を持つべき日、でもあるのかもしれない。

そしてこういうことを書いているうちに、南北戦争のリパブリック讃歌にある

As he died to make men holy,
let us die to make men free,
While God is marching on.

が思い起こされた。最後に勝つまで連戦連敗だった北軍の兵が負けてなお歌っていたことを昔アシモフのエッセイで読んで以来、おりに触れ蘇るフレーズ。

let us die to make men free. 人間を自由にするために死のう。

逆ではなく。

今日はそういう日です。

「帰りの会の世界」を生きそして死ぬ

「資本主義批判」みたいなやつをオレはまったく信用してなくて、というか、素人の浅墓なたわごとだと思っている。


投資の果実を投資者が直接得なくてもよいのであれば、もっともリターンがでかいのは教育投資。政府がシステム的に子供にカネをつっこめば本人の人生の充実という形で得られるリターンは非常に大きく、そのおこぼれの税収アップだけで政府はやっていける。みたいな考え方を市場経済が嫌いな人はやりにくいのでもったいなく思う。


科学とカネ勘定は人生の両輪である。


カネ勘定の問題がわかるというのは生物としての人間がわかるということにほとんど等しく、資本主義が生き残るという現状は、ヒトという種の作り出す社会の「計算結果」であり、どうしようもなくビビッドに現れている単なる表徴である。批判しようがどうしようが、それはそこにある。

 

もちろん、生物としての必然を客観視してそこに人為的な調整を加えうる、というのは人類の強烈な強みであり、市場を調整することで全体最適を制度化することが sapiens たる人類には(理論的には)可能である。

 

ただ現状のように、カネが流れてくるようになった場所に偶然立っていた人間がカネを握り、カネという結果を得ることで自分の実力を過信し、カネにより権力にも影響を及ぼすことができる社会で、カネを取り上げる施策が可能であるとはとても思えない。

 

たとえば自民党は二代目アホアホ経営者のお仲間集団であり、それらしいことをなあなあに言い含めるのが好きで上手だし、庶民はそういうのにとても弱い。全体最適は制度化しない。

 

小学校が解体される時代にならないと、こうした帰結がもたらすせせこましい社会が変わることはないのだろうと思っている。

 

国民性は小学校で作られ、われわれは今も「帰りの会」の世界に生きている。たとえ理性と議論がまともな結論を出したとしても、「先生」の鶴の一声がすべてを覆すことにわれわれは耐えてしまう。自分たちで不安な未来を選び取るだけの胆力がない。そうした国民性が変わるには、小学校が消滅し、個々に選び取る教育が普及するのが最上だと思う。

 

それまで待っていられないのであれば、小学校に関わる大人を増やすことで学級運営の呪いを解き、小学校を民主化する、という方法も存在する。(「学級運営の呪い」とは、学級崩壊により授業が成立しなくなることの不利益が他のすべての不利益より大きいという教諭間のコンセンサスにより保たれている非人間的学級運営慣行のすべてである)。

 

関わる大人は高度化しなければならない。教育学部出身者の教育法以外の知識はほぼすべてが一般人レベルで、学校には、そして教育委員会には、もっと現代的な知性が必要だ。数学嫌いだった教師に算数を教えさせるから、掛け算順序のような不毛な問題が起きる。

 

小学校はもっとも数の多い学校であり、多数の人間を配すには多量のカネが要る。

 

しかし、この投資を無駄だと思うのはカネ勘定のできない人で、教育投資のリターンがどれほど優れているのか身を以て体感しているはずの国家公務員たちが、あるいは収支を合わせるのに汲々とし、あるいは下手の横好きの一般的投資に走って、いずれも結果を出せていないのは、要するに彼らにはカネ勘定ができていないためだ。

 

科学とカネ勘定は人生の両輪である。それは政府の運営にもっとも必要な資質でもある。

 

しかし、「科学」を手に入れるには学問への傾倒が、「カネ勘定」を手に入れるには市場での経験が(できれば身銭を切ってひどい目にあった経験が)必要だ。どちらもハードルが高く、どちらも持ってる人はだいたい黙って満足に暮らしている。

 

政府の運営に関わる人達に科学とカネ勘定を無理やり注入するのがいいのか、制度を改めて在野のこうした人たちを活用するのが良いかといえば、目的達成が容易なのは圧倒的に後者だ。

 

しかし日本では制度が抜本的に改まることはないし、「無理やり注入する」方の策がとられたとしても、注入できた「ことにする」員数主義のショートカットが横行し、けっきょく何も変わらずに終わるだろう。小学校が解体される時代まではこれが続く。

 

さて。小学校が解体されるまで100年、その教育で育った子が社会の中枢に至るまで50年として、150年後くらいには、もしかしたら日本も少しは変わるかもしれない。

 

しかし、あなたが生きている間に変わることはない。「帰りの会の世界」を生き、そこで死ぬしかない。

 

大多数が政治に無関心な社会とは、こういうものである。

Mermaidで矢印をめちゃめちゃ繋ぐと楽しい

ボックスと矢印で関係性を記述したグラフがたいへん簡単に描けるMermaidというツールを使ってみたので紹介します。

構成図が描きたい

ひとつ前の『Nextcloudをロードバランシング』という記事を仲間内で見せたところ、わけわかんねえよ構成図描けよ、と言われたので、気になってたMermaidというグラフマークアップツールを使ってみました。

mermaid-js.github.io

こいつはテキストで内容物をゴジョゴジョっと書くだけでグラフ(ノードとエッジで構成された数学的な意味のグラフ…なんだけど、実はパイチャートとかも描けるらしい)が描けてしまうというツール。トップページにいろいろ載ってる。

mermaidトップページの画像

マークアップに必要な文法の解説もいろいろあるんだけど、オレはとりあえずライブエディタkubernetesのチュートリアルの例を突っ込んで、いろいろいじってカラダで覚えました。

それで出来た図がこれなんだけど:

さっきの記事の図

こいつがこのくらいの記述でできるわけです:

graph LR
client-->thenet[Internet]-->router[<b>FreeBSD</b><br>ルータ兼 <br> ロードバランサ<br>兼Redis<br>Nextcloud予備];
router-->linux[<b>Linux</b><br>Nextcloud]
linux --> windows[<b>Windows</b><br>dbserver]
router .-> windows
subgraph home[家]
router
end
classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
class router,linux,windows,ingress,service,pod1,pod2 k8s;
class thenet plain;
class home,cluster cluster;

ここで使った要素は:

  • graph LRで左から右に行く図
  • 文字を書くとそのままノードになる(router[<b>FreeBSD</b><br>ルータ兼 <br> ロードバランサ<br>兼Redis<br>Nextcloud予備]のように名称と表記を分けられる)
  • 矢印で関係性を記述
  • 囲み部分はsubgraph
  • 色付けや装飾はclassDefで書いたものをclass宣言で割当て

という感じ。

気に入ったのが、こいつはグラフ(数学的な)記述ツールなので、エッジ(矢印)を適当に足したり引いたりしてやると、関係性のガラっと変わったグラフが一瞬で描けてしまうこと。

上図にたどり着くまでは紆余曲折あるのでお見せしましょう。まずは最初のバージョン。

最初のバージョン

なんか関係性がヘンです。dbserverはルータじゃなくてNextcloudと通信するでしょ?とかそういうの。それで直したのが次。

ver. 2。もうこんなもんでええやろ

一気にわかりやすくなりました。

これでいいじゃんと思ったんだけど、いらんバージョンアップをしてみる。

構成図を見たがためにわからなくなる例

いやー、Linuxが調子悪かったらFreeBSDからdbserverにアクセスすることもあるんですよ、といいながら足してみたら一挙におかしな感じになりました。

ちょっと矢印の意味が統一されてないよね? アクセスの流れと頻度でやろうかな。ということで整理:

 

まだなんかおかしい

いや、これって単にFreeBSDマシンから見た流れだよね? もうユーザー視点で整理したほうが良くね?  ということで出来たのが完成版:

完成版

頻度を反映したり

頻度を反映しよう

矢印増やしたくない? てことで足したり

あかんやろ

みたいなことが、数行のコピペだけでできてしまうわけです。

これらは以下のように、コードの記述的には「linux --> windows」の行を増やしたり

 linux --> internet
 windows --> client

の2行を足したりしてるだけです。やるなグラフ理論

Mermaidのページに初めてアクセスしてから最初のバージョンを出すまでに30分くらいかかってますが、そのあと最後の図までの足したり引いたりは、全部で20分とかです。グラフ最高!!

Joplinで使えます

もうひとつ大事なことがあります。最後の2枚はOnline Editorじゃなく、Joplinに標準で入ってるインラインプラグインで描いてるんです。

JoplinはEvernote代替を目指してるノートアプリですが、組み込みのMarkdownエディタがたいへん強力で、書いたMDが即座にフォーマットされるライブコーディングエディタになってます。

そしてmermaidに関しても、記述が即座に図に反映されてくれます。つまり、だいたい手元で完結してていじり放題です。

さいきんは50人くらいのクラスで授業とかやってるんで、資料作りが大変だったんですが、こんな感じで定形に流し込むだけで関係性を記述できるグラフが簡単に描ける、しかもその場で…! ほとんど夢のようです。

いやー、便利な世の中になったよね。やり放題ですわ〜。

Nextcloudをロードバランシング

たいへん遅いマシンで動いているNextcloudの負荷を少しでも分散したいシリーズ。今回はロードバランシング。バックエンドのサーバは1台だけで、まったくロードバランスできてないけどロードバランス構成をとりたい。やりたいからやる。という話です。

ちゃんと書こうと思ってたけど、書いてみたら何をやったか結構忘れてて、後から読んだらわけがわからなそうな備忘録ができました。いつものことだ。

分散には成功したので、バックエンドのサーバは今後その気になれば増やせるけど、全体的な狙いはどちらかと言うと、なんでもやらせすぎな家サーバの負荷分散です。

ちょっと前に、dbサーバにWindowsマシンを投入しましたが、今回は、非力だけど家サーバよりは強いCPUを持ちSSDも積んだLinuxマシンを投入してウェブサーバとし、こいつにNextcloud本体の負荷(php-fpm)を

丸投げします。

目標

以下の形を目指しました。

構成図
  • 新サーバはUbuntu22.04ltsのノート。CPUはCeleron 1000Mと、これまたどんくさいCPUを積んでますが、FreeBSDマシンよりは高速でメモリが8GB、SSDが1TBあるのでNextcloudしか動かさなければ軽そう。
  • ロードバランサはFreeBSD 13の家サーバ。CPUがAthron Neo N36Lの10年以上前のマシンですが、メモリは16GBでディスクは20TBくらい積んでる(ZFS)。これまでのNextcloudサーバそのもので、今後もルータでありファイルサーバでありトラブル時の代替サーバです。

やったこと

  1. 新サーバでテストインスタンスが動くとこまで持っていく。
    • phpモジュール等のインストールや設定が済んでないと引っ越しもできないため、 一番簡単な条件出しとして、実際に /var/www/nextcloud-test にサラからインストールして動かす。 
    • Nextcloudのインストールはこれの通りに普通にやる:

      Installation and server configuration — Nextcloud latest Administration Manual latest documentation

    • nginxはhttpのみに設定する(listenを443→80に)
    • phpは22.04の標準の8.1がNextcloud未対応ということで使えず、8.0を

      How to Install PHP 8.0 on Ubuntu 22.04 LTS - LinuxCapable

      に書いてあるとおりにしてインストール。
    • phpまわりのモジュールのインストールや設定はいろいろあるけど、まあドキュメントのとおりにやれば大丈夫。 
      • ただしメモリキャッシュは複数のNextcloudを動かすのに備え、APCuに加えRedisも使って分散キャッシュやファイルロックができるようにしておく。Redisはこれまでのサーバで動いてるのでこれを使う。
      • (ちなみにデータキャッシュはウェブサーバが1台だけならAPCuの内部キャッシュだけでよい。Redisが動いているのは、元サーバのNextcloudインストール時にドキュメントに書いてあるものを闇雲に全部動かしたため。同様の経緯でmemcachedも動かしたが、こちらはまったく不要なので今回止めた。)
      • php-fpmだけでなく、コマンドラインから使うoccなどがメモリキャッシュを使えるように(しないとエラーが出る)、/etc/php/8.0/mods-available/apcu.iniでapcまわりの設定をしておく。
  2. ロードバランサでのSSLアンロード & HTTP変換実験
    • これまでのサーバにはSSLアンロードとRedisサーバを担当してもらう。
    • httpのロードバランサ(リバースプロキシ)にはHAProxyとかあるけど、nginxのみの簡単な設定で行ける
    • 参考ドキュメント:

      How To Set Up Nginx Load Balancing with SSL Termination | DigitalOcean

    • このドキュメントはけっこう長いけど、それはSSLを動かすところやウェブサーバがロードバランサとしか通信しないようにするところなどに紙幅を割いているから。
    • ウチでは元のサーバでSSL自体は動いていたし、後背はイントラネットでロードバランサ=ウェブサーバ間のセキュリティはあまり考える気がないため、骨の骨の設定である "Virtual Host File And Upstream Module" という項の内容しか多分やってない。
      • これは本質的にはnginx.confで2箇所設定するだけ:
      • upstream mywebapp1 {
            server 10.130.227.11;
            server 10.130.227.22;
        }
      • server {
            listen 80;
            server_name example.com www.example.com;
        	
            location / {
                proxy_pass http://mywebapp1;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
            }
        }
      • upstreamはserverに前置して設定する。
      • upstreamで設定した名前(この例ではmywebapp1)を server 内の location / のproxy_pass に渡す。
      • mywebappをhttp://でアクセスするのがキモ。たったこれだけとは!
    • Let's Encryptのワイルドカードな証明書を使っているので、既存インスタンスのホスト名をnextcloud、新サーバにリダイレクトするホスト名をnextcloud2として設定した
      • server項を書き足して既存のNextcloudインスタンスと分けて
      • upstreamとhttpで通信する
  3. 新サーバで旧サーバの環境をNFSマウントしてテスト。FreeBSDUbuntuhttpdを担うユーザーのデフォルトのUID/GIDが違ってて面倒だったが、Ubuntu側でFreeBSDと同じ80:80にして解決。これで解決してくれるUbuntuはすごく楽。もうそれなりに動く。
  4. 新サーバで旧サーバの環境をrsync(80GBに5、6時間かかった。Joplinの細かいファイル群が重い)で丸コピーしてテスト。ちゃんと動く。あとは、テストインスタンス側のconfig/config.phpのoverwrite関係だけが「設定」の「概要」にある「セキュリティ&セットアップ警告」に引っかかる状態。
  5. 旧サーバを止めてrsyncし直して(今度は4分しかかからず)切り替え。overwrite関連は、Reverse proxy — Nextcloud latest Administration Manual latest documentation の最後のとこにあるExampleとにらめっこして設定したので、「セキュリティ&セットアップ警告」も「すべてのチェックに合格しました。」となる。よしよし。
  6. すっかり安定して動いてると思ってたら、スマホアプリから写真がアップロードできず、さんざん悩んだ。 request entity too large とか言ってくる。
    • これはロードバランサのnginxでclient_max_body_size 512M; を入れてなかったため
    • ロードバランサはただ投げるだけかと思っていたら、デフォルトの制限などは効いてくるのでした。
    • 何が起きてるのかまったくわからなかったが、NextCloudで413エラーが表示される問題【Nginx】 というページで納得。
    • 手を抜いて安心してた場所でひどい目にあうのはいつものことだね…。

ともあれ完成です。あとはこれを丸コピーすれば複数のインスタンスで動かすことも可能。

感想

むちゃくちゃ速くなりました!…相対的には。

絶対的にはまだ微妙な性能です。Talkアプリをタップしてからチャンネル一覧が出るまで、たっぷり5秒かかる。以前は12秒くらいかかってたので人間的なスピードになったけど、まだ満足とは言い難い。

分散によって実験しやすくなったので、今後もいろいろ投入してみたい。

今後やりたいこと

これやりたい。

  • 新サーバが止まる時には元サーバを上げておきたい
  • 元サーバのNextcloudは普段は止めておくが、nginxの設定をいじるだけで動かせる状態にはしておきたい
  • というわけで、新旧サーバでファイルの同期は取っておく必要がある

から。

旧サーバのNextcloudインスタンスは新サーバにNFSマウントしてあり、そのままローカルファイルシステム同様にアクセス可能なため、同期そのものはrsyncで容易に取れるわけです。

Nextcloudの構成はwebサーバ、ストレージ、データベースから成る。ウェブサーバは今回設定し、データベースはdbサーバをそのまま使うので、あとはファイルの同期だけ取れば、すぐに復旧できる。

NFSのキャッシュを頑張るとか、Union FSを使うとか考えたんだけど、realtime rsyncでぐぐったら出てきたlsyncdが便利そう。lsyncdはディレクトリに変更があったら即座にrsyncを走らせて同期をとってくれるやつです。

ちょっと今週はもう時間がないけど、次はこれを入れようと思います。

NextcloudをSSL無しで使う

備忘録。

NextcloudをSSL無しで使うには、httpdの方の設定を変えます。Nextcloudの方はいじらない。ウチはnginx。

  1. listenするポートを443から80に
  2. ssl_certificateとssl_certificate_keyの行を削除
  3. fastcgi_param HTTPS on; の行を削除

でいけます。

Nginx Example Configurations — Nextcloud 9 Server Administration Manual 9 documentation

より。Wayback Machineの奥底に眠ってる古いドキュメントです。

・・・・

SSLを外すとか、まあ普通はそんなことやらんと思うんですが、SSLターミネーション付きのnginxロードバランサの後ろにNextcloudサーバを置いて、

 

Nextcloudサーバ ==http== ロードバランサ(ルータ)==https== インターネット

 

という形にしたい。で、いま内部のネットワークでテスト用のNextcloudを動かしてるんですが、それでちょっと詰まった箇所のメモ。

元情報:

I don't want to use HTTPS - ℹ️ Support - Nextcloud community

NextcloudのデータベースサーバをM1なMac miniにまかせたら死んだ(オレが)

 

Nextcloud便利だけど重い

Nextcloudという「オープンソースのSynology」みたいな、ファイルサーバーベースのウェブアプリケーションスイート("self-hosted productivity platform")があります。

ウチではDropboxの代替として導入したところ、家族用のSlackを内部アプリのTalkで置き換え、Evernote代替のJoplinの保存先として設定し…という感じで順調に依存度を高めてます。

ところが、これが動いてる家庭内サーバが遅い。HP Proliant Microserverという10年くらい前のSOHO用サーバで、NTT-Xストアで2万くらいで買えたために一時期流行ったモノ。ドライブベイが5本あってeSata接続されてるので足回りはそこそこ速いものの、CPUが当時の省電力タイプ(AMD Athlon II)なので、NextCloudみたいな Web サーバ + PHP + DB構成の現代的なサーバープログラムを動かすにはいかにも力不足。*1

PHPのアップデートやキャッシングやJITコンパイラの導入など、できることはやりつくしました。

さすがにもうこのサーバは古すぎるなあ、新しいのほしいけど、この手の部内用サーバってクラウドに置き換えられて絶滅しちゃってるんだよなあ…。

高可用性への道

と思っていたところ、こんなドキュメントを見つけました。

An Insiders Look into scaling Nextcloud by Matthias Wobben

Nextcloud社はサーバをオープンソースで開発しつつ商用サポート版とかを売る商売をやってまして、これはそのセールスエンジニアが書いたプレゼンです。

アーキテクチャ解説の部分に、こんな連続図がありました:

全体の構成



Nextcloudプログラム本体



データベース



ファイル群



分ける

 

ふむふむ・・・と見ていって、9ページでスパッと分かれたのを見たときは、思わず「かっけー!」って叫びましたね。なんかとろくさいと思ってたNextcloudは、実はキレイに分割できるアーキテクチャになっていた。

Nextcloud社では、この形で(さらに負荷分散を加えることで)最大5万から10万ユーザーを実現してるとのこと。プレゼンの後半には実際の導入例とかが載ってました。

いやーすばらしい!

このスケーラビリティは、モダンなウェブアプリなら当然ちゃあ当然…なのかもしれませんが、オレは自分で実用的にいじってるものがきちんと分散できる状況にあったことがなく、むしろ複数のサーバを仮想化で1台にまとめるとかの事例ばかり見てきたわけです。

だから、眼の前のものを分割してパフォーマンスブーストができる、という事例を現実感を持って眺められたことで感動しました。こいつはやってみたい!!

家庭内ロードバランシングしてみる

それで自分ちのことを考えてみると、特に重いのがデータベース。MariaDBというMysqlの派生プロジェクトのやつで、Mysqlより(もちろんSQLiteとかよりはずっと)速いらしいんですが、NextCloudを使っているときにtopで監視してると、

  1. MariaDBがCPUを100%近く使う
  2. 数秒で落ち着くと、いくつも起動してるphp-fpmのチャイルドプロセスがそれぞれ20-50%ずつ使う
  3. 数秒で落ち着くと、手元の表示が出始める

というパターンが頻出します。データベースとphpが足を引っ張ってる。データベースが片方の足を、phpがもう片方の足を引っ張って、思い切り沼に引き込まれてる感じ。

これらのCPU boundな処理を外注できれば高速化できそうです。

んで、データベースサーバは切り出すのに最適です。

まず、

  • もともと分離されてるのが本来の形だから簡単なはず

である上に、

  • 使用容量が小さい
  • CPUとdisk I/Oが重い

というデータベースサーバの条件が、

  • CPUパワーを余らせてる
  • ディスクは250GBで小さすぎ

というM1 Mac miniにピッタリだったから。

mimi(M1 Mac mini の hostname)、キミに決めた! 働いてもらうぜ!

Mac mini M1にMariaDBをインストールして分散

さっそくmimiでport searchしてみるとmariadb-10.8-serverというのが見つかりましたのでインストール。元のサーバのmariadbデータのバックアップを持ってきて流し込み、アクセス権を設定し、元のサーバのNextcloudのnextcloud/config/config.phpを編集して接続できるようにしました。

それで動かしてみたら速い!…?

速いんだけど、思ったほどではないっすね~。php-fpmが処理の大部分の時間を使っていて、こちらのほうが重い。反応時間は2/3くらい。

Mac mini M1にphp-fpmをインストールして分散

それではこのクソ重いphpもmimiにまかせてしまいましょう。mimiにphpをインストールして、Webサーバのnginx.confのlocalhost:9000をMac miniに向ける…ん? 動かない。

オレは勘違いしてました。php-fpmの動いてるマシンにリダイレクトするだけで分散できるんだろうと。この勘違いは、nginx.confのphp-fpmの設定にあります。phpの処理はlocalhostのポート9000に飛ばすようになっている→ということは、データも何もかも一緒に飛ばしてくれるんだよね? と。だってデータベースサーバってそういう分割なんですもん。

ところがphp-fpmは、phpスクリプトを直接処理できないウェブサーバのための機構であり、phpスクリプトとはもともと簡易な動的なページ生成(「ホームページ」を訪れたら中に現在時刻が出てるとか)のためにあります。ここらへんはデータベースサーバとは根本的に違った出自だからしょうがない。

というわけで、これは処理部分だけ飛ばすわけにはいかず、プログラムやデータの入ったファイルシステムが見えている必要があります。(上の分割図でいうところのWebサーバ部分)。

Mac mini M1でファイルサーバからnfsマウントして分散

で、元のサーバからこのあたりをnfsエクスポートしてmimiでマウントして実験してみると…なんかファイルシステムが見えない。index.phpを処理しに行ったphp-fpmプロセスが返ってきません。

しかもここでトラブル発生。mimiのmariadbがCPUを使い切って暴走してます。元のサーバからのアクセスをそのままにして実験したのが悪かった? しかしデータベースなんて複数マシンから同時アクセスされるのが普通じゃないの??

とりあえずmimiのnginxを止めて、mariadbは再起動。

諦めてデータベースサーバの分散だけでよしとする…だがしかし

とりあえず調子良く動いているので安心していたところ、夜になって急にNextcloudの反応がなくなりました。504 Bad Gatewayとか出る。

nginxのログを見てみるとphp-fpmがタイムアウトしてます。これはデフォルト60秒なので、Nextcloudのアップデート時なんかには出ることがあるエラー。

そんなに負荷が高いのかと思って、サーバでtopを見てみると…静かなもんです。いつもよりぜんぜん使われてないというか、php-fpmが上に来てない。

ps auxw | grep phpで見るとphp-fpmのプロセス自体は動いてる。なのにnginxに処理が戻らない。なんか起きてますな…。

変わったことといえばmariadbの分散…というわけでmimiを見てみると、なんかMariadbの負荷が高いですね…。ちょっと再起動してみる。反応変わらず。

とりあえずこの時点でデータベースのバックアップを取ってみる。テーブルが壊れてるとかならバックアップもまともに取れないだろうから、そのときは移行したときのバックアップまで巻き戻す…あれ? 普通にバックアップ取れる。データベースじゃないのか…。

php-fpmのエラーログを見ても、特にエラーは出てない模様。php.iniかなんかでログレベルをdebugまで上げてやると、チャイルドプロセスの展開状況を毎秒知らせてくるレベルでログを吐くんですが、これをやっても出ない。

サーバの環境がなにかぶっ壊れたかなあ、とphpを一旦アンインストールして再インストールしてみたり、はては

freebsd-update upgrade

までやってみたけど、やっぱりphp-fpmの処理が返ってこない状況は変わりません。

やっぱりやっぱりデータベースじゃないの?と思ってmysqlコマンドで接続してみると、普通に接続できる。やっぱりデータベースじゃないのか…と諦めて寝ました。

データベースをWindowsに移してみる

もともと24/7でまったく止まらずにちゃんと動いていたものが急に調子が悪くなり、しかも原因不明となれば、変えたところがおかしいに決まっているわけです。

しかし負荷分散してアプリを軽くする実験を後退させたくもない。

そしてデータベースサーバは本当に何にでもインストールできる。

というわけで翌朝。これもわりに遊んでるくせに高速な、図書室のWindows 10マシンにMariadbをインストールしてみました。管理の作法がいろいろ違っててめんどくさかったけど、サクッと入って快調に動作。

(軽くハマったのはデータベース本体の管理。「データベースサーバプログラムに接続できるように設定する」ということと「特定のデータベースに接続できるように設定する」ということって違うのね…。mimiに入れたときもやったはずだけど、まだ慣れてない)

それでこちらのデータベースに接続してみると…Nextcloud復活したよ!!

macOS is not UNIX!!

大人しくしてればいいものを実験を続けました。せめてphpを分散できないかなあと。

しかしMacのnginxがNFSマウントしたボリュームの中のファイルを全く読めない。

これはphp-fpmとの絡みを考えたくなかったので静的ファイルで実験したり、macOS特有のファイルアクセス制限を逃れるために置き場(nginxのdocument root)をいろいろ変えたりしたんだけど、どうしても読めないんですね。nginxの設定そのものがおかしい?と思って/Users/me/Public/の下にindex.htmlを作ってやるとあっさり読めるんですが、同じファイルがNFSの中に入ると読めない。

しかもこれ、エラーはPermission DeniedではなくOperation not permittedが出る。

そうはいってもやっぱり権限問題なんじゃない?と思って sudo _www cat index.html とやると普通に読める…。

サーバ側の設定がおかしいのかもなあ…と思って、Pop!_OS(Ubuntu派生のたいへん使いやすいデスクトップLinux)の入ったノートPCでnfsマウントしてみると、めちゃめちゃあっさりnginxから読めるw

というわけで、ブン投げました。Macはサーバにならん。

さらに頑張ってなんとか動かしたとしても、またAppleが破壊的な変更をやってくるだろうということが容易に予想がつくので、学習資源が再利用不能すぎるんですよね。

なのでmimiはそういうことに使わないでよし。です。php-fpmの処理だけならRasPi4とかでも現行サーバよりは軽くなるはず。

ふりかえり

mimiのMariadbは最新版を入れたんですが、マシンがM1であることを考えると、バージョンが新しすぎたかも。次に実験するときは、よく枯れたやつを入れてみます。それでも十分速いはずだし、謎のエラーが出なくなるなら素晴らしい…しかし出なくなるかなw

*1:CPU Markは478とかで、10万オーバーな最新のRyzen Threadripper PRO 5995WXの1/200とかしかありません。何だよ10万オーバーて。ベジータ様か。