My Best Articles

nginxのメトリクスとログをモニタリングをする メトリクスデータは以下のように流す nginx -> vector -> kafka -> opensearch/influxDB という感じで、nginxから出た生ログをvectorでとり、kafkaに送信、kafkaから、opensearchとinfluxDBがそれぞれとってくる、という流れにするのが良さそう で、nginxがログを吐き出し/var/log/nginx/access.logとvectorを同じネームスペースで扱いたいので、この二つは物理マシン上にインストールするという流れにしたいと思う。 環境構成 以下の3つのマシンを使う delta (100.64.1.48,192.168.3.1) : 192.168.3.1/24のルータ,kafka, kafka-ui, opensearch master (192.168.3.8) : プロキシサーバ（nginx）、vector gamma/zeta/　: オリジン kafkaを導入するdocker composeの設定 services: kafka-broker: image: apache/kafka:3.7.0 container_name: kafka-broker ports: - "${KAFKA_BROKER_LOCAL_PORT}:9092" environment: KAFKA_NODE_ID: 1 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT" KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT_HOST://localhost:${KAFKA_BROKER_LOCAL_PORT},PLAINTEXT://kafka-broker:${KAFKA_BROKER_PUBLIC_PORT}" KAFKA_PROCESS_ROLES: "broker,controller" KAFKA_CONTROLLER_QUORUM_VOTERS: "1@kafka-broker:${KAFKA_BROKER_CONTROLLER_PORT}" KAFKA_LISTENERS: "CONTROLLER://:${KAFKA_BROKER_CONTROLLER_PORT},PLAINTEXT_HOST://:${KAFKA_BROKER_LOCAL_PORT},PLAINTEXT://:${KAFKA_BROKER_PUBLIC_PORT}" KAFKA_INTER_BROKER_LISTENER_NAME: "PLAINTEXT" KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER" KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1 KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS: 0 KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1 KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1 KAFKA_LOG_DIRS: "/tmp/kraft-combined-logs" kafka-ui: container_name: kafka-ui image: provectuslabs/kafka-ui:v0.7.2 ports: - "${KAFKA_UI_PORT}:8080" depends_on: - kafka-broker restart: always environment: KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS: kafka-broker:${KAFKA_BROKER_PUBLIC_PORT} init-kafka: # kafka-topics コマンドを使いたいので confluenticsのコンテナを利用 image: confluentinc/cp-kafka:7.6.1 container_name: init-kafka depends_on: - kafka-broker entrypoint: ["/bin/sh", "-c"] command: | " # blocks until kafka is reachable kafka-topics --bootstrap-server kafka-broker:${KAFKA_BROKER_PUBLIC_PORT} --list echo -e 'Creating topics' kafka-topics --bootstrap-server kafka-broker:${KAFKA_BROKER_PUBLIC_PORT} --create --if-not-exists --topic nginx-log --replication-factor 1 --partitions 1 echo -e 'Successfully created :' kafka-topics --bootstrap-server kafka-broker:${KAFKA_BROKER_PUBLIC_PORT} --list " opensearchを導入する設定 version: '3' services: opensearch-node1: # This is also the hostname of the container within the Docker network (i.e. https://opensearch-node1/) image: opensearchproject/opensearch:latest # Specifying the latest available image - modify if you want a specific version container_name: opensearch-node1 environment: - cluster.name=opensearch-cluster # Name the cluster - node.name=opensearch-node1 # Name the node that will run in this container - discovery.seed_hosts=opensearch-node1,opensearch-node2 # Nodes to look for when discovering the cluster - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 # Nodes eligible to serve as cluster manager - bootstrap.memory_lock=true # Disable JVM heap memory swapping - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Set min and max JVM heap sizes to at least 50% of system RAM - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD} # Sets the demo admin user password when using demo configuration, required for OpenSearch 2.12 and later ulimits: memlock: soft: -1 # Set memlock to unlimited (no soft or hard limit) hard: -1 nofile: soft: 65536 # Maximum number of open files for the opensearch user - set to at least 65536 hard: 65536 volumes: - opensearch-data1:/usr/share/opensearch/data # Creates volume called opensearch-data1 and mounts it to the container ports: - 9200:9200 # REST API - 9600:9600 # Performance Analyzer networks: - opensearch-net # All of the containers will join the same Docker bridge network opensearch-node2: image: opensearchproject/opensearch:latest # This should be the same image used for opensearch-node1 to avoid issues container_name: opensearch-node2 environment: - cluster.name=opensearch-cluster - node.name=opensearch-node2 - discovery.seed_hosts=opensearch-node1,opensearch-node2 - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 - bootstrap.memory_lock=true - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD} ulimits: memlock: soft: -1 hard: -1 nofile: soft: 65536 hard: 65536 volumes: - opensearch-data2:/usr/share/opensearch/data networks: - opensearch-net opensearch-dashboards: image: opensearchproject/opensearch-dashboards:latest # Make sure the version of opensearch-dashboards matches the version of opensearch installed on other nodes container_name: opensearch-dashboards ports: - 5601:5601 # Map host port 5601 to container port 5601 expose: - "5601" # Expose port 5601 for web access to OpenSearch Dashboards environment: OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]' # Define the OpenSearch nodes that OpenSearch Dashboards will query networks: - opensearch-net volumes: opensearch-data1: opensearch-data2: networks: opensearch-net: nginxを導入する設定 これは普通に ...

LBのあれこれ 参考文献 https://qiita.com/masaozi3/items/838060d7339aef01bc2e

ネットワークの中心は一体どこなのか？ これの答え、ついに具体的にわかったわ。 インターネットの発祥地はアメリカと言うのは有名な話だよね。 あとは、ネットワークのネットワークがインターネット、と言う話も有名な話だよね じゃあ、そのネットワークの中心はどこなのか？と言う話だが。答えは、「Tier 1 Network」に所属するISPだとおもう。詳しく述べよう。 参考文献 cloud flairのBGPの説明 Tier 1にはsoftbankも入っているのか？ インターネットのすごくわかりやすい説明 昔の資料。平成１５年とかなので2003年とか。まだソフバンが来る前の話 日本のISPの話 日本のISP一覧 asn/ipの取得方法 トランジットとピアリングの話 closネットワークの話もここでしています 回線事業者とISPの関係 学術ネットワークの話 Tier1 ISP はい、Tier1に所属するISPは世界で16個しかないんだよね。 こいつらは、インターネットバックボーンを形成しているISP。 で、インターネットバックボーンの役割は、海底ケーブルなどを介して、大陸間、国家間にまたがって各国の基幹ISPを相互接続して、大容量データの経路を確保することです。つまり、国家間の通信を可能にするためのケーブルを弾いてくれている。 日本の企業でTier1のISPに入っているのは、NTTとソフバンが買収したSprintっていうアメリカの会社。 で次。 日本の一次プロバイダ 宮城さんの話 janogでは、ISPの人たちがピアリングをしましょうとか、そういう交渉の場としても使われる。これはだいぶ面白いね。 また、個人がISPになることもできるって話。これは、AS番号をもらうって話になるのかな？

家事 8/13 R 風呂掃除 皿洗い T 昼ごはん 洗濯 コンロ掃除 8/14 R T 朝ごはん 昼ごはん

プライベートIPアドレス Class A: 10.0.0.0 to 10.255.255.255 This range supports a large number of hosts and is often used in very large networks. Class B: 172.16.0.0 to 172.31.255.255 This range is commonly used in medium-sized networks. Class C: 192.168.0.0 to 192.168.255.255 This range is typically used for smaller networks, like home or small business networks. 合計いくつあるのでしょうか？ class Aは2^24くらいいけね？つまり？ >>> 2**24 16777216 はい、classBは？ >>> 16*2**16 1048576 classCは？ >>> 2**16 65536 グローバルIPアドレス はい、グローバルIPね。JPNICとか、そのへんによって管理されているやつね。 2^32個ありますね、はい。そこから上のクラスのを抜いていきます 2**32 - 2**24 - 16*2**16 - 2**16 =4277075968 それでも40億箱しているって話ね。しかしだよ。これすごく重要なこと言います。実はまだグローバルに割り当てられていないIPが存在するんです。知ってましたか？？（初耳） ...

事始め 新卒研修も終わりに近づき、配属が近くなってきた。 研修を受けて学んだことも多くあったので、忘れないように記事を書こう。 全職種共通研修についてはここではハブらせてもらう。 研修のスケジュール Java Spring boot Server + linux 個人での開発 チームでの開発 Java Javaで学んだことは、 そうだなー、すべてがクラスだってことかな。慣れてくるとそんなに悪いものでもない気がする。 ただ、マルチスレッド処理の記述方法がほかの言語とは違うからちょっと気を付けた方がいいかもしれない。 ああ、あとすごく勉強になったのはインターフェースだね。インターフェースを使うことでクラスのインターフェースを定義できる。 どういうことかというと、 インターフェースによって、ポリモフィズムを実現できる、という話だ。 ポリモフィズムとは「メッセージが同じでも、それを受け取るオブジェクトによっ て動作が異なること」だからね。 インターフェースを作っておいて、それを実装するクラスを作る、んで、インターフェース名で変数を作っておいて、そこに紐づけるオブジェクトは、 インターフェースを実装したクラス。これによって、例えば、インターフェースを配列で保持して、各要素ごとに同じメソッドで違う処理をさせることができる、っていう話だね。ハイハイ。 Spring boot ここはいろんなことを学んだね。 DIという概念 単体テストという概念 WEB開発でのレイヤードアーキテクチャの話。 DIをすることでコンポーネント間の依存関係を疎結合にできる、って話だな。インターフェースを定義しておいて、その実装を注入する。 注入されたコンポーネントを使う側のクラスは、何を注入するかだけを考えればいい。中の実装はどうでもいい。だからテストと本番で切り替えることもできる。 あとは単体テストだね。今までは全く意識してこなかったが、確かに、各メソッドについて簡単な単体テストを書いた方がいいに決まっている、という話だな。 WEB開発でのレイヤードアーキテクチャ。これもだいぶいい学びになった。そうね、UIとAPIに分けて開発するっていうのもめっちゃ勉強になったし、その中でも特にAPIでController + Service + repository + Mapperに分けてやるってのだいぶ勉強になった。これからもこのレイヤーは守って進めていきたいなって感じだな。 server + linux ここは特に学んだことはないかなーー。でも、SQLのjoinについてはかなり学んだのでjoinとかそのあたりかな、だから改めてページを作ってまとめていきたいよね。あーー、あとはCI/CDについても学んだな。これはだいぶいい学びだった。Jenkinsを学んだね。しかし、Github Actionsの方がよさそうっていう感想。これも改めてまとめたいね。 個人開発 Spring bootの演習でやったことを個人でもう一回やるって感じだった。ただ、Javaを使ってWebシステムを構築する方法がわかったね。 チーム開発演習 これはマジで勉強になった。特にチームでの開発方法、めっちゃ勉強になった。作業分担の仕方だね、 うちのチームではコンポーネントの依存関係を意識してタスクを振ったけど、これが完全にはまったね。横軸を機能、縦軸をそのサービスを実現するためのコンポーネント（Controller, Service, Repository）で見た時、バックエンドは縦の依存関係が圧倒的に強かった。そもそも縦の依存関係は必ず生じるのだけれどもね。一方で、フロントはほかの機能との横断的な依存関係が多かった（それもそうだよね、APIっていう道具を使ってフロントの人は処理するからね）。こういうときはいっそレイヤーごとに担当を分けてしまった方がすっきり行く。特に最上位層はユーザがみるデザインなわけで、そこを一人の人が開発したのはデザインに統一感が出せてむしろ良かったって話だよね、マジで。 あとは、設計と見えるかの重要性かな。とくにMiroを使って、ワイヤー、そしてそれを実現するための機能、その機能を実現するためのコンポーネント、とか、レイヤードアーキテクチャを設計するときの方法、めっちゃ勉強になった。 あとは、タスク管理ツールだね。GithubのProjectを立ててIssue化することができるって話よ。んで、Git + Githubについてもマジでいろんなことを学んだね。チームメンバーでgitに詳しい人がいてね。それもまとめておきたいね。 うちのチームはかなりスピーディーに開発が進んだけど、これはひとえに設計をちゃんとやって、みんなで共有できたから。この開発方法は一生の宝になると思う。しかし、実現方法がわからないものに出会ってしまったらどうやるのかな。空中分解型アジャイルとかやるのかな。 まとめ Java : インターフェース、ポリモフィズム Spring Boot : DI, 単体テスト、レイヤードアーキテクチャ server + linux : CI/CDツール（Jenkins, Github Actions）, SQLのjoinやgroup by　（個別の記事として出す） 個人開発演習：なし チーム開発演習：タスクの振り分け方、Miroを使って設計を見えるかすること、タスク管理をgithubですること。 (Gitの使い方として新しい記事を出す)

learn_k8s_2! はい、前回がk8sクラスタの構築部分でした。ここからは実際に運用をどうするか？ってところに焦点を当てていきたいと思います。 前回の冒頭の記事はいい感じだったので、ここにも書いておきたいと思います。 ことはじめ k8sという技術が注目を浴びている。web業界での近年の大きな変化としてはアプリケーションアーキテクチャの変化が挙げられる。従来は、アプリケーションを構成するソフトはモノリシック(一枚板)であった。つまり、アプリケーションは、一つのソースコードで1プロセスで動いているような感じだった。しかし、このモノリシックなアーキテクチャではソースコードが複雑で、変更が加えにくい等の問題があった。チームで開発する際も、メンバーみんなが同じソースコードをつかってビルドをする必要がある等、いろいろと面倒なことが多かったと思う。そこで、近年はアプリ開発にはマイクロサービスアーキテクチャが採用されている。マイクロサービスアーキテクチャは、小さなコンポーネントの集合が全体として一つのアプリケーションを構成しているようなアーキテクチャである。 自分も意図せずして、開発してきたアプリはマイクロアーキテクチャにしていたが、こちらの方が各コンポーネントの役割をきちんと明確化して進められるので、開発を分担できるのと、変更を加えるとき、役割がコンポーネントに分かれているので、各コンポーネントの中身だけを変えればよく、管理が簡単になると思われる。つまり、APIだけそろえておけば、後は中身はなんだっていいということだ。 これによって、アジャイル開発が非常に簡単になると思われる。 そして、このコンポーネントをひとつひとつをコンテナ化するってのも近年の大きな流れだ。コンテナ化することで、そのコンテナはCPUのアーキテクチャさえそろっていればどんなマシン上でも動くようになるからだ。そして、コンテナ化されたコンポーネント（マイクロサービス）をうまく協調させるのが コンテナオーケストレーションツールってはなしだ。 コンポーネントを協調させる、と書いたが、具体的には(k8sの機能は非常に多いので、俺が理解できる、かつ、大事そうなものだけをピックアップする)、 コンテナのスケジューリング スケーリング/オートスケーリング 障害時のセルフヒーリング ロードバランシング ワークロードの管理 とかがある。 k8sの基本的なコンポーネント 参考動画 基本用語説明 dbと連携させたjsアプリを題材に、k8sのコンポーネントを説明していくよ！ cluster k8sのリソースを管理する集合体のこと node 物理マシン、もしくは仮想マシンのこと。つまり、ホストのこと。 ノードには、master nodeと普通のnodeがある。 master nodeはkubernetesを管理するため、次の管理コンポーネントを持つ kube apiserver:kubernetesのAPIを公開する。kubectlからの操作を受け付ける役割。kubeletからもアクセスを受けるし、他にもいろいろなクライアントがある。これがclusterへのgatewayになる。ユーザは必ずkube apiserverを通してクラスターとやり取りをするということだね。 etcd:分散kvs。クラスタのバッキングストアとして使用される。ログとかが記録されている。etcdは分散kvs、ということはetcdを何個か立てることが可能、ということでして、そうするとetcd間で内容の一貫性を保たないといけないわけですね。ということは？お？層です。分散合意アルゴリズムのraftが使われているわけですね。最高です。 kube scheduler:コンテナを配置する最適なnodeを選択する。ここも研究の対象になりえるところではある。 kube controller manager: リソースを制御する k8sでソフトで実現される概念的なコンポーネント (下で紹介するが、これをリソースと呼ぶ。) Nodeはコンテナ化されたアプリケーションを実際に実行するホスト pod コンテナの集合体。PodはNodeの中で動作し、一つ以上のコンテナを持つ。 K8sにデプロイするときは、Pod単位で行う。(実際はdeployという単位でコンテナをデプロイするんです) pod一つでなにか機能を果たす、とかそういう感じでpodにまとめるのだと思われる。 そうだね、1 application per Podというのが基本らしい。 k8sはvirtual networkを提供。各Podはこの仮想ネットワーク上でIPアドレスを持っている。 そして、これが結構大事な概念だんだが、Podは結構簡単に死ぬ。そして、Podが死んだら、新しいPodがデプロイされるのだが、その時にIPアドレスが変わってしまうというのが不便らしい。その時に使うのがServiceらしい。 Container Dockerコンテナのこと ReplicaSet 同一仕様のPodを複数生成する仕組み。 ReplicaSetを複数持っておくことで、一つのReplicaSetが死んでも他のReplicaSetに 処理を移すことでシステムが死んでいる時間をなくす。 後は、ロードバランスもできる。 データベースは基本的にk8sクラスタの外で管理する。というのも、ステートを考えるのが面倒くさいかららしいです。 Service Serviceは、Podにアクセスするための経路を定義。 PodのIPアドレスを固定できる。 外部への公開ポイントもここで設定する。 Deployment ReplicaSetの上位リソースで、ReplicaSetを管理する。 つまり、 DeploymentがReplicaSetを管理し、ReplicaSetがPodを管理する。 ingress クラスタ外部からのエンドポイント？ ConfigMap Podsの設定ファイル ...

まえがき Go言語はhttpサーバに使われることがおおいー＞これは、現代のシステムがマイクロアーキテクチャに依存していることを示している。一つ一つのコンポーネントは単純な入出力に対応しているだけである。そのため、シンプルなgo言語が好まれるのだろう。 さらに、goの人気を上げているのが、並行処理の扱いやすさにある。 一般的な言語では、スレッドを立てて、スレッド間でなにか、スレッドセーフなコンテナを準備してやり取りをしないといけなかった。 しかし、goでは、goroutineとchannelを使って、スレッド間通信のようなものがかんたんにできるのがかなりいい。 以上の２つの要因によって、goではデータの流れがだいぶ見やすくなっていると思う。川上から川下へ流れていくがごとく、データの流れがとにかくつかみやすい。 goで特徴的なもう一つの機能は、インターフェースだろう。 これについては、後ほど説明する。 第一章 環境構築 https://go.dev/dl/から最新版をダウロード。tarで解凍。/usr/local/いかにgo/をおいて、そこにパスを通す。 echo 'export PATH=$PATH:/usr/local/go/bin' >> $HOME/.profile source .profile ここで疑問なのだが、どうやら、go/はホームディレクトリいかにもおいておかないとだめみたいなんだ。 というのも、ダウンロードしたモジュールやパッケージはホームディレクトリ以下のgo/に置かれるかららしい。 まあ、よくわからんよね。じゃあ、/usr/local/いかにおいたgoは何だったんだとね。 実行 go run hello.goでも実行できるし、 go buildで、コンパイルもできる。go自体はコンパイル言語。go runは直接実行しているように見えるが、内部的にはgo buildで一回ビルドしている。 ちなみに、go buildで出力される実行ファイルは.go前の部分。だから、hello.goをコンパイルすると、helloという実行ファイルが生成される。これを変えたい場合は、-oで実行ファイル名を変更することもできる。 モジュール まあ、c++やcの分割コンパイルみたいなことができるって話で、モジュールを作ってみましょう、ということ。 mkdir hello-world cd hello-world go mod init hello-world これで新たにgo.modというファイルが出来上がる。 go install goはgo installコマンドでgoのバイナリをインストールできる便利なコマンドである。 ためしに、heyという、httpサーバのロードテストを行えるツールをインストールしてみましょう。 go install github.com/rakyll/hey@latest デフォルトではホームの下の~/go/binにインストールされます。なので、ここにもパスを通す必要がありますね。 が、変えたかったら、$GOPATHを変えましょうって話ですね。まあ、変えることはあまりおすすめしませんが。 で、goで作ったファイルはこんな感じでかんたんに公開できるわけですね。 goのコードのフォーマット 無意味な宗教戦争を産まないために、かなりフォーマットに制限があるという話。こういうのは結構好き。例えば、 main(){ } と main () { } みたいな。goでは後者はコンパイルエラーになる。 開発ツールにgo fmtやgoimportsというものがあり、これはプログラマーが書いたソースをきれいにしてくれるフォーマッターである。 他にもstaticcheckという名のりんたーがある。 これは、まあ、コードを解析してくれるツールです。きれいなコードを生み出してくれるということで、ありがたい。 第二章 変数の定義について色々教えてくれています。これは実際に書いていくなかで勉強していくほうがいいのではないかと思っているのです。 ただ、変数の命名規則は結構勉強になった。 go言語ではスネークケースはあまり使わないと。これは俺が好んで使うやつだね。 comp_calcみたいな感じ。でもこれはあまり使われないらしい。で、キャメルケースのほうがいいって話。うん。たしかにそっちのほうが主流な気もしてきたな。 あと、goでいいなって思ったのは、定義した変数を全部使わないとコンパイルエラーが出るところ。これでいらない変数を全部排除できるって話です。 三章 配列、スライス 配列は、 ...

やりたいこと webアプリケーションを家のサーバで動かすとなるとセキュリティーの観点からして怖いじゃないですか。やっぱり自宅のipさらしたくないじゃないですか。 だからAWSなどのVPSを借りてそのうえでアプリを動かすんだと思います。 ただね、VPSでは二次記憶で使えるデータ量が決まっているんですね。しかもそのデータ量が結構限られています。例えば僕が契約しているサーバは二次記憶の容量が30GBです。つまり、大規模なデータベースを展開するには、大幅な課金が必要になるわけです。しかもさ、データベースを移植するのって結構面倒だからさ、一回構築したやつを長く使いたいんです。だからね、データベースだけは自宅においておき、アプリケーションが自宅のDBにデータをとりにきたり、おきに来たりすればいいのでは？と今思っているわけです。DBクライアントがデータを取ってくる時の通信量も考えるとどっちが安いかはまだわからないんですけどね。 じゃあ、自宅のルータをポート開放して、ポートフォワードすればいいんじゃねーの？って思うよね。でもね、データベース用のポートを開放しておくのもなんか怖いんですよ。ブルートフォースとか受けて、破られることもあるわけじゃないですか。ということで、vpnを介して自宅のネットワークにアクセスできるようにしておけばいいのではないか？というのが僕の考えです。 vpnクライアントのインストール sudo apt update sudo apt install openvpn vpnクライアント、設定ファイルのインポート config.ovpnをサーバに配置 sudo openvpn --config /path/to/my/ovpn/file パスワードを入力してトンネル完了 openvpnを介して自宅のmysqlサーバに接続 mysql -u ray -h 192.168.3.10 -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 473 Server version: 8.0.33-0ubuntu0.20.04.2 (Ubuntu) Copyright (c) 2000, 2023, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> いけてしまっている…これはマジで感動！！ネットワークはやはり面白い。仕組みとかはもっと勉強しないといけませんが。 いやー－－、実際これはすごいです。マジですごいですわ！！感動ですわ。 ...