2021-11-12

【雑記】国産クラウド（もしくは官公庁で使うクラウド）

デジタル庁が採用したクラウド事業者がAWSとGCPという話を受けて個人的に思ったことをツラツラ。

はじめに

www.yomiuri.co.jp

３社から応募があったが、安全面や事業継続性など約３５０の要件を満たした両社を採用した。

相応の基準をもって選ばれたと思いますし、応募３社からの選定とのことなのでそもそも応募もしていなかったかもしれないので、勝手な思いです。

偏った私見を交えつつ、僕が選ぶんだったらこうするかなぁと順番に。
改めて断っておきますが、何の根拠もないただの感想です（逃げまくり）。

あと国産クラウドといいつつ、富士通以外は情報を持ち合わせていないので非国産クラウドだったりします。

まぁそれくらい緩い雑記と思っていただければ。

富士通

FUJITSU Cloud Service : 富士通

国産クラウドであるべきかどうか分かりませんが、富士通は国産クラウドサービスを提供しています。
官公庁のサービス基盤として、選べるのであれば国産の方が日本人ならではの細かさへの対応を含めて融通があるように思います。

国内基盤ということは機密に関するデータも扱います。
それが海外サーバに配置されることが個人的には好ましいとは思いません*1。
（基本事項のサービス全般に「情報資産はユーザが指示しない限り日本国内に保管されること。」とのことなので、AWS・GCPでも要件は満たされていると考えて良さそうですね）

東京リージョンとして独立しているとは思いますし、おそらく先の選定基準の中でも言及されているとは思いますが、デジタル戦争的な話を考えたときに「日本が海外のネットワークから遮断されるリスク」もあるような気がします。

富士通は富岳といった国産基盤を構築や機密保持のノウハウがあると想像するところもあります。

エンタープライズ系としては Java EE（Jakarta EE）や PostgreSQL などのOSSへの貢献を長く行っています。
富士通は東京証券取引所での大量データ高速処理を汎用機からサーバをベースとする基盤にリプレイスした実績もありますし、メーカーとしてサーバー製造できるということは「非常にコアな処理を物理で殴る」ことも出来るという事だと思います。
また東証のように大きめの規模の基盤を準備しておいて有休資材を「官公庁クラスのセキュアな基盤」として民間利用に回すことも出来るかもしれません。

クラウド業者という意味ではメジャーではないのですが、かつてはOracle クラウドのパートナーだったりするので相応のノウハウはあるんじゃないかぁと（Oracleから提携切られはしましたけど）。

ちなみにアプリケーション実行基盤としての使いやすさについては、後述他を含めて昨今 Kubernetesをベースとしているのでそのレイヤーでの差はあまりないのではないかな？と思っています。

MicroSoft（Azure）

ここ数年のOSSへの取り組みや、マネージドなサービスへの取り組みが基盤利用者フレンドリーに感じるからというのがあります。

また、これはJJUGの懇親会で、クラウド基盤をそのままワークステーションのように持ち運べるサービスもあるというの伺ったことがあるから。
物理的にオンプレとクラウドをシームレスに利用できるというのは官公庁としては扱いやすいと思います。先にも挙げたようにネットワーク的に日本が海外と断絶したとしても、こういうサービスがあれば災対としても有効だと思います。同じように災害時に狭い範囲（といっても市町村自治体レベル）で独立したサブ官公庁システムを搬入することで早期の部分的復旧も出来るように思います。

Office365をベースとした企業環境基盤も既にあり、そのあたりを新規で作り込まなくて良いというメリットもあるように思います。富士通もProjectWebとかあるんでしょうけど、、最近色々ありましたし。。あとOffice系サービスは利用現場においても必要なので MS系で固めてしまって運用の簡便化を図っても良いかなと。

基盤の上のサービスはNTTデータ、富士通、NEC、日立などのベンダーが行うとして、MS系がベースにあるのはオールインワンとして便利だと思います。

IBM（Red Hat）

MSとは僅差というか、同着というかそのくらいの位置。
未知数は日本対応。
東京リージョンはあるので、物理データ置き場がグローバルでミラーされる可能性はAWSやGCPと同じ（それをいえばMSも同じかもしれないけど）。
違いは、富士通の時と同じくハードメーカーの側面があるところ。
ソフト面については Red Hatを含めた多彩さに期待。
とくに実行基盤とアプリの間を埋める部分となるOS周りは Red Hatの強みかなと思う*2。

Javaベースの実行基盤としては WildFly もあるし、Camelとか分散システムの実行基盤ミドルウェア製品などの面が強いイメージがあります。

ルール駆動開発あたりもユーザー主導でシステム構築をするときに有効活用できるんじゃないかなぁ。

その他

Oracleもよぎったのですがクラウドサービスに限れば、そんなことは無いのかもしれないのですがいかんせん高いというイメージが拭えないんですよね。
あと、数年前まで富士通が日本国内の基盤サポートをしていたという記憶があり、だったら運用ノウハウのある富士通で良いんじゃないかな？と。

参考リンク

デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供－令和3年度地方公共団体による先行事業及びデジタル庁WEBサイト構築業務－｜デジタル庁

（詳細未読）

さいごに

まぁ、、あれですね。自分の嗜好先であるJavaと日本IT利用者に親和性があるんじゃないかな、という順みたいな感じになっていますね。
かなり縁故含めてバイアスがありありだとも思います。
再掲ですが、何の根拠もないただの感想です。別にAWSやGCPが悪いとか言っているわけではありません。
こんな意見もあるんだなというところで。

*1:データの置き場所の法令に従った扱いになるという認識のため

*2:実際はDockerに吸収されるところなのかもしれないけれど

2021-08-30

VirtualBoxの共有フォルダ設定

VirtualBox

いつも忘れる、VirtualBoxの共有フォルダ設定のメモ

ツールのインストールに必要なものをインストール

sudo apt install gcc make perl -y

VirtualBoxツールをインストール

インストールディスクを挿入

ディスクのフォルダへ移動

sudo sh VBoxLinuxAdditions.run

ゲストOS再起動

ユーザーをvboxsfグループに加える

sudo gpasswd -a (ユーザー名) vboxsf

共有フォルダを設定

ゲストOS（Linux）のmnt/nas へマウントしたい場合*1

f:id:vermeer-1977:20210830092036p:plain — 共有フォルダ設定

*1:サーバーキッティングの予行演習なので外部ストレージ疑似としてNASへのマウントを意図しています

2021-08-23

文字列をBase64に変換する

Java

はじめに

ファイルパス（もしくはそれに準ずる文字列）をURLパラメータに使いたいと思いましたが、そのままではエスケープをあれこれしないといけないし、マルチバイトが入ってくると長くなります。そこで文字列をバイナリー圧縮してBase64変換したら良いかな？と思ってやってみました。

開発環境

Java 11

何が嬉しいの？

文字列にURLに使用不可な文字があっても使用できる*1
文字列の難読化（暗号化ではない）ができる

変換処理

処理の流れは以下の通り

文字列をバイナリー圧縮する
バイナリーをBase64に変換する
URLに使用してはいけない文字列を置換する

デコードは、この逆をします。

実装

import java.util.Arrays;
import java.util.Base64;
import java.util.logging.Logger;
import java.util.zip.DataFormatException;
import java.util.zip.Deflater;
import java.util.zip.Inflater;

public class StringCompressor {

    private static final Logger logger = Logger.getLogger(StringCompressorImpl.class.getName());

    public String deflate(String value) {
        byte[] input = value.getBytes(java.nio.charset.StandardCharsets.UTF_8);
        byte[] output = new byte[256];
        Deflater compresser = new Deflater();
        compresser.setInput(input);
        compresser.finish();
        int compressedDataLength = compresser.deflate(output);
        var trimed = Arrays.copyOfRange(output, 0, compressedDataLength);
        var base64 = Base64.getEncoder().encode(trimed);
        var encoded = new String(base64, java.nio.charset.StandardCharsets.UTF_8);

        //base64で使用されていてURLで使用されることが推奨されていない文字を置換
        var replaced = encoded
                .replaceAll("\\+", "_")
                .replaceAll("/", "-")
                .replaceAll("=", "!");

        return replaced;
    }

    public String inflate(String value) {
        try {
            // deflateで置換した文字列をbase64用に置き換える
            var base64 = value
                    .replaceAll("_", "+")
                    .replaceAll("-", "/")
                    .replaceAll("!", "=");

            var decoded = Base64.getDecoder().decode(base64);

            Inflater decompresser = new Inflater();
            decompresser.setInput(decoded);
            byte[] output = new byte[256];
            int resultLength = decompresser.inflate(output);
            decompresser.end();

            var result = new String(output, 0, resultLength, java.nio.charset.StandardCharsets.UTF_8);
            return result;
        } catch (DataFormatException ex) {
            logger.warning(() -> ex.getMessage() + "::String could not decode " + value + "::");
            return value;
        }
    }

}